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FOREWORD 


This  report  entitled  "TRADOC  RAM  Data  Evaluation 
System  (TRADES)”  is  an  American  Power  Jet  Company  (APJ) 
study  effort  issued  in  five  parts: 

Part  I:  Executive  Summary  and  Brief 

Part  II:  Study  Work  Plan 

Part  III:  System  Requirements 

Description 

Part  IV:  Alternative  Concepts 

of  Operation  (This  Report) 

Part  V:  System  Technical  Paper 

This  Part  of  the  final  report  explains  the  five  ACOs 
which  were  developed,  and  includes  a  comparative  evalua¬ 
tion  of  these  alternatives  along  with  the  recommendation 
to  use  the  U.S.  Army  Logistics  Center  Planning  Factors 
Data  Base  (PFDB)  mini-computer. 

A  draft  version  was  submitted  as  APJ  892-3,  and  pre¬ 
sented  to  the  SAG.  Their  comments  and  recommendations 
are  incorporated  herein  and  are  gratefully  acknowledged. 
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CHAPTER  I 
INTRODUCTION 

SYSTEM  TITLE 

The  title  of  this  study  is  the  "TRADOC  RAM  Data 
Evaluation  System  (TRADES)  (ACN  51235):  Phase  II". 

References  made  to  the  acronym  "TRADES"  throughout 
this  report  will  refer  to  the  TRADOC  RAM  Data  Eval¬ 
uation  System  and  not  to  the  present  study. 

SUBJECT  OF  THIS  REPORT 

This  report,  entitled  "Alternative  Concepts  of 
Operation  (ACO)"  addresses  the  third  task  in  a 
series  by  the  American  Power  Jet  Company  (APJ)  for 
the  U.S.  Army  Logistics  Center.  Two  previous  re¬ 
ports  covered  the  development  of  the  Study  Work 
Plan  (SWP)  and  the  System  Requirements  Description 
(SRD).  This  ACO  report  will  be  followed  by  the 
System  Technical  Paper  (STP)  and  the  Final  Study 
Report  (FSR),  which  will  incorporate  all  the  pre¬ 
vious  reports.  A  more  detailed  description  of  each 
task  is  provided  in  the  SWP  and  SRD. 

BACKGROUND 

The  need  for  TRADES  has  evolved  due  to  the  ever- 
increasing  complexity  of  weapons  systems  and  the 
need  for  the  combat  developer  to  establish  standards 
to  ensure  that  these  expensive  systems  will  work 
when  fielded.  Realistic  RAM  parameters  and  thresh¬ 
olds  must  be  prescribed  which  are  based  on  user 
needs  for  system  effectiveness  and  logistics  sup- 
portability  in  view  of  system  design,  state-of-the- 
art  technology,  and  performance  achieved  by  fielded 
equipment.  Great  care  must  be  taken  in  establishing 
RAM  requirements  because  of  their  significant  effect 
on  development  and  operating  and  support  costs,  and 
on  equipment  readiness. 

TRADES  is  envisioned  as  an  information  system  which 
would  provide  the  TRADOC  combat  developer  with  re¬ 
sponsive  near  real-time  automated  reliability,  avail¬ 
ability,  and  maintainability  (RAM)  information.  This 
would  include  engineering,  test,  and  field  data,  and 
would  provide  the  capability  to  support  requirements 
determination  and  test  analyses  for  materiel  under 
development.  A  complete  summary  of  TRADES  and  its 
background  is  included  in  the  SRD. 


PHASES 


The  TRADES  study  effort  has  three  phases:  Phase  I  es¬ 
tablished  the  requirement  for  a  TRADES  system;  Phase 
II  (the  current  phase)  in  essence  portrays  the  concept 
for  TRADES;  Phase  III,  if  approved,  will  address  the 
implementation  of  TRADES  as  an  operating  system  for 
the  TRADOC  community.  It  should  also  be  noted  that, 
although  the  system  is  being  developed  for  TRADOC, 
other  potential  users  in  the  Army  have  been  identified. 

PURPOSE  OF  THE  ACO  STUDY 

The  purpose  of  the  ACO  study  is  to  evaluate  four 
ACOs  for  TRADES,  recommend  a  preferred  alternative  to 
the  Study  Advisory  Group  (SAG),  and  provide  the  vehicle 
to  enable  the  SAG  to  select  the  best  course  of  action 
for  STP  development. 

The  Statement  of  Work  (SOW)  and  guidance  from  the  SAG 
requires  a  consideration  of  concepts  which  would: 

1.  merge  the  TRADES  function  into  the  USALOGC  Planning 
Factors  Data  Base  (PFDB) 

2.  merge  TRADES  into  the  USALOGC  Maintenance  Task 
Demand  (MTD)  file 

3.  merge  TRADES  into  the  Automatic  Data  Processing 
Equipment  (ADPE)  concept 

4.  be  selected  by  the  contractor. 

These  four  concepts  were  briefed  in  general  terms 
at  the  previous  SAG  and  are  presented  in  detail  herein. 
Each  concept  description  includes  the  overall  concept 
of  operation,  organizational  elements,  procedural  des¬ 
cription,  and  automatic  data  processing  equipment 
(ADPE)  hardware  and  software. 

SCOPE  AND  SUMMARY  OF  CHAPTERS 

The  SRD  covering  the  TRADES  requirement  conceptual 
structure  of  systems  satisfying  that  requirement  was 
completed  in  July  1981,  and  was  approved  with  minor 
corrections  by  the  TRADES  SAG  in  August  1981.  The 
present  report  provides  four  ACOs  which  will  be  des¬ 
cribed  in  detail  and  analyzed,  and  will  recommend  the 
best  alternative  concept  to  implement  TRADES. 

Chapter  I  (Introduction)  provides  the  background  to 
TRADES  and  to  this  report. 

Chapter  II  (Methodology)  describes  the  methods  used 
to  determine  the  facts  leading  to  the  description  of 
the  ACO  alternatives  and  the  recommended  alternative. 
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It  also  includes  a  general  description  of  the  over¬ 
all  TRADES  concept  which  the  four  ACOs  will  ad¬ 
dress.  (This  insures  equal  capabilities  for  each 
ACO  described  in  Chapters  IV,  V  and  VI  below. ) 

Chapter  III  (Evaluation  Criteria)  establishes  the 
criteria  used  for  comparison  and  evaluation  of  the 
four  ACOs.  These  criteria  were  reflected  in  the 
SWP  and  further  detailed  in  the  SRD. 

Chapters  IV,  V,  VI  and  VII  present  and  discuss  four 
ACOs  (PFDB,  MTD,  and  ADPE,  and  the  Stand-Alone 
Alternative  developed  by  APJ).  These  four  alterna¬ 
tives  are  presented  in  terms  of  organizational,  pro- 
ced’  ral ,  and  ADPE  requirements . 

Chapter  VIII  (Analysis  of  Alternatives)  uses  the 
evaluation  criteria  discussed  in  Chapter  III  to 
compare  the  four  alternatives  described  in  Chapters 
IV,  V,  VI,  and  VII.  The  advantages  and  disadvantages 
of  each  alternative  are  portrayed  and  discussed,  to 
enable  the  reader  to  understand  the  different  oper¬ 
ating  environments  and  procedures  for  each  ACO. 

Chapter  IX  (Conclusions)  summarizes  significant 
findings  of  the  analyses  conducted  in  the  preceding 
chapters. 

Chapter  X  (Recommendations)  contains  APJ's  recom¬ 
mendation  of  the  ACO  to  be  selected  for  TRADES. 


CHAPTER  II 


METHODOLOGY  AND  APPLICATION 


GENERAL 


In  general  terms,  a  comparative  analysis  may  be  con¬ 
ducted  in  two  ways.  One  method  holds  the  required 
capabilities  of  the  alternative  roughly  equal  (cetera 
paribus),  and  measures  the  differing  costs.  The 
second  method  considers  a  fixed  level  of  resources, 
and  measures  the  resultant  product  of  each  alterna¬ 
tive  under  consideration. 

For  this  study,  the  first  method  is  considered  more 
appropriate  since  it  is  clear  that  the  requirements 
portrayed  in  the  SRD  must  be  met  for  any  system  selec¬ 
ted  to  perform  the  TRADES  function.  Figure  2-1  shows 
the  methodology  map,  which  leads  to  the  recommendation 
of  the  preferred  alternative. 

Thus,  this  chapter  establishes  the  functional  and  or¬ 
ganizational  requirements  to  which  each  ACO  must  be 
designed.  It  sets  forth  all  characteristics  of  TRADES 
which  must  be  common  across  all  ACOs  to  be  considered 
of  "equivalent  capability". 

ESSENTIAL  ELEMENTS  OF  ANALYSIS 
(EEA)  RELATIONSHIPS 

From  the  concept  of  equal  capability,  it  can  be  seen 
upon  examination  of  the  EEAs ,  that  of  all  factors  used 
in  the  analysis,  the  methodology  will  produce  signifi¬ 
cant  differences  in  primarily  two  areas:  (1)  Resource 
Requirements  and  (2)  Implementation  Time.  Therefore, 
conclusions  and  recommendations  resulting  from  this 
study  are  based  primarily  on  the  findings  from  these 
two  areas.  These  relationships  are  graphically  shown 
in  Figure  2-2. 

TRADES  LIFE  CYCLE  OVERVIEW 

In  accordance  with  AR  18-1  and  TB  18-100,  TRADES  life 
cycle  is  comprised  of  five  major  phases  in  relationship 
to  the  management  milestones.  (See  Table  2-1.) 


o  RESPONSIVENESS 


o  ACCESSIBILITY 
o  EEI 

o  FLEXIBILITY 

o  integration 

o  BACKUP 
o  GROWTH 

o  QUALITY  CONTROL 
o  SECURITY 


VS 


o  RESOURCE  REQUIREMENTS 
o  IMPLEMENTATION  TIME 


Figure  2-2.  Relationship  of  Essential  Elements  of  Analysis 


TABLE  2-1.  PHASE/MILESTONE  RELATIONSHIPS 


PHASE 

MILESTONE 

I  - 

Feasibility  Studies 

0  -  Approval  of  MENS 

II  - 

Concept  Development 

I  -  Selection  of  Concept  to  be 

Demonstrated 

III  - 

Definition/Design 

II  -  Decision  to  Develop  System 

IV  - 

System  Development 

III  -  Decision  to  Deploy  System 

V  - 

Dep 1 oymen  t/ Ope  ration 

As  shown  in  Table  2-2,  Phase  I  (Feasibility  Study)  has 
been  completed.  TRADES  is  now  in  concept  development 
with  the  present  effort  developing  and  evaluating  ACOs. 
The  final  product  of  this  phase  will  be  the  development 
and  selection  of  the  final  concept  (corresponding  to 
Milestone  I),  with  the  description  presented  in  an  STP. 

The  next  phase  of  the  work  program  will  concern  the 
definition  and  design  of  the  accepted  TRADES  system 
prior  to  Milestone  II-  A  major  initial  effort  in  Phase 
III  will  be  the  organization  of  the  data  base,  and  de¬ 
velopment  of  the  appropriate  taxonomy  to  facilitate 
RAM  data  searches,  and  to  provide  for  efficient  and  ef¬ 
fective  categorization  of  the  data  base.  The  organi¬ 
zation  of  the  data  base  and  development  of  the  tax¬ 
onomy  will  provide  major  inputs  to  the  actual  design 
of  the  system  to  complete  Phase  III. 

Phase  IV  consists  of  the  TRADES  system  development, 
with  the  initial  effort  in  prototyping  the  system 
prior  to  Milestone  III. 


TABLE  2-2.  TRADES  LIFE  CYCLE  OVERVIEW 


PHASE 

FEASIBILITY 

I 

CONCEPT 

DEVEL. 

II 

— 

DEFINITION/ 

DESIGN 

III 

1 

DEPLOYMENT 

OPERATION 

V 

MATURE 

SYSTEM 

Function 

Need 

Determi nation 

ACO 

Eval'n. 

Info. 

Organiz'n. 

Program 

Debug 

Proto¬ 

type 

Initial 

Use 

Update 

Modif' ns. 

PIP 

System 

Design 

Full  Scale 
Implem'n. 

Status 

Completed 

In- 

Progr. 

IBP 

* 

HE 

As  discussed  elsewhere,  this  prototyping  could  ad¬ 
dress  a  single  data  source  as  an  initiation  point 
for  debugging  the  system,  and  then  progress  into 
full-scale  implementation  of  total  RAM  data  sources. 
This  implementation  would  then  develop  into  Phase  V, 
the  actual  deployment  and  operation  of  TRADES. 

Although  TRADES  will  not  likely  require  DA  level 
approval  (developmental  costs  are  anticipated  to  be 
less  than  $3M),  AR  18-1  functions  as  an  umbrella  over 
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all  Army  automation  management.  Therefore,  the  pro¬ 
visions  of  this  regulation  must  be  recognized,  and 
recommendations  for  TRADES  are  within  the  perimeters 
of  this  regulation. 

TRADES  SYSTEM 
CONCEPT  ORGANIZATION 

To  ensure  that  the  ACOs  considered  in  this  program 
provide  equal  capability,  general  TRADES  characteris¬ 
tics  and  organization  are  set  forth  below.  Inherent 
differences  among  the  ACOs  are  based  on  the 
method  by  which  the  program  organization  can  be  im¬ 
plemented,  and  the  time  and  resource  requirements  of 
each. 

The  basic  TRADES  system  concept  includes  five  modules 
which  are  controlled  by  a  master  TRADES  executive 
program.  These  modules  (shown  in  Figure  2-3)  include: 

1.  Source  Identification 

2.  Interface 

3.  Quick  Response 

4.  Statistical/Analytical 

5 .  Management . 

Source  Identification  Module 

This  module  is  the  basic  vehicle  by  which  RAM  data 
users  can  query  a  central  repository  for  all  sources 
of  appropriate  RAM  data.  It  contains  a  logical  organ¬ 
ization  or  taxonomy  of  all  commodities  of  interest  to 
RAM  data  users,  to  the  commodity,  end  item,  major 
system,  or  subsystem  levels.  Selected  components  may 
also  be  entered  as  required.  This  module  will  provide 
the  user  with: 

1.  Agency  and/or  activity  with  appropriate  RAM  data 
holdings 

2.  Form  of  data  (hard  copy,  automated  unclassified 
and/or  secure  data  bases) 

3.  Extent  of  holdings  (years  of  information,  number 
of  test  reports,  total  number  of  records,  etc.) 

4.  Form  of  data  (test  reports,  raw  field  data,  re¬ 
duced  data,  analysis  results,  etc.) 

5.  Environmental  conditions  (e.g.,  peacetime  vs  combat, 
geographical  area,  arctic  vs  tropical,  desert  vs 
cultivated  areas,  etc.) 


6.  Point  of  contact 

7.  If  automated  data  base: 

a.  Accessibility  through  user  terminal 

b.  Necessary  passwords,  machine  interface, 

baud  rate,  etc. 

c.  Protocol  and  procedures  for  obtaining  data. 

In  the  event  that  an  automated  data  source  is  identi¬ 
fied  in  query,  this  module  will  provide  complete  des¬ 
cription  of  file  layouts  (essential  elements  of  infor¬ 
mation  (EEIs)  in  each  field  of  data),  together  with 
necessary  identification  and  definition  of  terminology 
to  provide  the  user  with  information  relative  to  user 
requirements  which  may  be  matched  by  the  data  base. 

Interface  Module 

This  module  contains  the  necessary  protocol  to  commu¬ 
nicate  with  the  diverse  computers  which  may  contain 
RAM  data  bases  within  DA  (or  other  military  services, 
as  required).  Access  to  the  interface  module  is  in¬ 
dicated  from  the  source  identification  module,  de¬ 
pending  on  the  specific  user  requirements  and  source 
identification.  To  the  extent  feasible,  this  module 
should  also  contain  adequate  software  to  provide  the 
user  with  a  basic  vehicle  for  extracting,  analyzing, 
and  formating  outputs  from  automated  data  sources. 


Quick  Response  Module 

This  module  provides  an  immediate  "acceptable"  value 
for  each  EEI  as  they  refer  to  all  items  in  the  tax¬ 
onomy.  These  values  are  provided  and  controlled  by 
individual  proponent  activities  that  are  authorized 
to  enter  a  "preferred"  value  for  given  commodity  ele¬ 
ments.  This  module  would  be  highly  dynamic  since  val¬ 
ues  are  entered  into  the  quick  response  portion  as 
user  requirements  arise.  System  RAM  requirements 
along  with  OMS/MP  from  the  ROC  will  be  entered  in 
the  Quick  Response  Module. 

Statistical/Analytical  Module 

All  tools  necessary  for  RAM  data  users  to  extract 
data,  formulate  tables,  carry  out  regressions  or 
time  series  analyses,  and  other  statistical/analyti¬ 
cal  procedures  with  minimal  manual  effort  are  pro¬ 
vided  by  this  module.  It  could  contain  readily 
available  software  packages. 


Management  Module 

This  module  serves  two  basic  functions: 

1.  Development  of  historical  information  for 
management  purposes 

2.  Automated  system  for  establishing  a  RAM 
"corporate  memory". 

For  proper  management  of  the  TRADES  system,  this 

module  will  include  historical  information  of  all 

transactions  including: 

1.  Who  used  the  system  and  how  often 

2.  What  EEIs  were  requested 

3.  Level  of  data  required  (commodity  area,  end  item, 
major  subsystem,  etc. ) 

4.  Frequency  of  response  indicating  hard  copy  only 

5.  Frequency  of  use  of  automated  data  bases  by  activity 

6.  Number  of  times  quick  response  file  was  used 

7.  Utilization  of  statistical/analysis  module 

8.  Necessary  administrative  information  required  for 
budgeting,  etc. 


The  management  module,  as  shown  in  Figure  2-4, 
provides  the  basic  vehicle  for  adding,  deleting  and/or 
changing  EEIs,  taxonomy,  software,  and  other  character¬ 
istics  of  the  overall  TRADES  data  system. 

For  its  second  function  (establishing  a  corporate 
memory  )  provision  is  made  for  recording  signifi¬ 
cant  outputs  from  any  RAM  query  as  they  relate  to  the 
equipment  taxonomy  item,  environment,  life  cycle  stage, 
and  date  of  query.  It  can  also  be  used  by  the  commodity 
proponents  to  make  entries  or  changes  to  the  quick  re¬ 
sponse  module. 

The  decision  to  place  the  "corporate  memory"  of  RAM 
analysis  results  in  the  management  module  was  made  pri¬ 
marily  on  the  basis  that  the  corporate  memory  is  not, 
as  such,  subject  to  change.  This  is  in  contrast  to 
the  quick  response  and  source  identification  modules 
which  are  subject  to  continuing  update  and  which  to¬ 
gether  represent  the  best  available  information  at  any 
given  point  in  time.  Nevertheless,  this  subject  will 
be  further  examined  during  the  preparation  of  the  STP, 
where  it  may  be  found  that  programming  convenience, 
coupled  with  properly  designed  access/modification  con¬ 
trols  may  permit  its  placement  in  another  portion  of 
the  implementation  structure. 


MANAGEMENT 

MODULE 


Review  Quick 
Response  File 
&  Corporate 
History  Files 


Review  TRADES 
Util 'n.  and  Service, 
«  Corporate 
History  Files 


Recommend 
updates  to 
proponents 

-Add,  delete,  change 
Interface  Module 
software,  as  req'd. 

-Add,  delete  EEIs, 
as  req’d. 

-Add,  delete,  change 
references  to 

Source/ Iden  ti f i cati on 
Module,  as  req'd. 

-Add,  change,  improve 
Statistical/Analysis 
Module,  as  req'd. 

Figure  2-4. 

TRADES  Management 

Functions 

SYSTEM  DEVELOPMENT 
AND  IMPLEMENTATION 


An  inherent  characteristic  required  of  each  ACO  is 
that  it  be  capable  of  being  prototyped  and  permit  its 
evolution  in  the  direction  of  maximum  customer  ser¬ 
vice.  This  infers  that  RAM  data  is  not  a  "once  and 
for  all"  requirement  set  by  current  RAM  requirements 
documents  or  users,  or  indeed  by  the  present  users' 
view  of  what  they  need.  These,  to  the  contrary,  are 
only  starting  points. 

Once  TRADES  is  operational,  it  must  respond  to  changes 
and  needs  of  the  user  community,  as  well  as  to  increas 
ing  availability  of  RAM  data  at  any  point  in  its  life 
cycle.  It  must  determine  weak  spots  in  the  source 
data  and  use  the  TRADES  system  to  secure  action  in 
areas  of  maximum  return.  This  implies  a  highly  compe¬ 
tent  TRADES  management  team,  comprised  of  human  beings 
using  the  computer  as  only  one  of  their  tools  in  meet¬ 
ing  their  missions  and  functions. 

The  ultimate  goal  of  the  overall  program  is  to  estab¬ 
lish  a  major  RAM  data  system  that  will  satisfy  user 
requirements  in  minimum  response  time.  It  must  be 
recognized,  however,  that  for  several  years,  the  sys¬ 
tem  will  be  operating  in  a  mixed  hard  copy/lightly 
automated  environment,  moving  toward  a  less  important 
hard  copy  and  more  important  automated  data  system. 

In  either  case,  hard  copy  data  must  be  recognized  as 
being  involved  in  RAM  data  somewhere  in  the  system 
at  all  times. 

Figure  2-5  provides  a  diagram  of  the  TRADES  RAM  data 
update  routine.  Primary  responsibility  for  this  func¬ 
tion  resides  with  the  proponent  of  the  specific  item 
for  which  the  RAM  data  is  being  updated.  However, 
basic  information  necessary  for  the  proponent  to  exer¬ 
cise  its  function  resides  in  the  management  module 
and  history  files.  Likewise,  any  actions  taken  in 
the  update  of  these  source  files  is  recorded  in  the 
history  files. 

TRADES  ACO  COMMON 
PROCEDURAL  CHARACTERISTICS 

The  TRADES  user  procedures  for  all  ACOs  are  the  same 
and  follow  a  progression  of  steps  in  a  sequential 
order.  When  a  requirement  for  RAM  data  is  identified, 
the  user  queries  the  source  identification  module  in 
terms  of  a  specific  EEI .  This  can  be  further  deline¬ 
ated  by  a  set  of  geographical  conditions,  local  en¬ 
vironments,  and  type  of  data  (DT,  OT,  field  data,  etc.) 


Following  procedures  depend  on  the  response  obtained 
from  the  source  identification  module.  If  data  are 
available  in  hard  copy,  arrangements  can  be  made  ex¬ 
ternal  to  TRADES  to  obtain  necessary  information. 

If  the  data  are  on  an  automated  base,  the  source  iden¬ 
tification  module  identifies  the  availability  or  acces¬ 
sibility  of  the  data  base.  If  the  resident  computer 
software  package  can  provide  the  necessary  output,  the 
interface  module  is  then  used  to  provide  the  necessary 
output. 

If  the  data  are  accessible,  but  the  resident  computer 
cannot  provide  data  in  usable  form,  data  is  then  ex¬ 
tracted  via  the  interface  modules,  stored  temporarily 
in  the  TRADES  computer,  and  the  necessary  output  pro¬ 
vided  by  the  statistical/analytical  modules.  Output 
report  generation  capability  is  available  either  in 
the  interface  module,  or  in  the  statistical/analytical 
module. 

DEVELOPMENT  OF  CURRENT 
"HARD  COPY"  RAM  DATA  REFERENCES 

As  noted  above,  a  major  portion  of  the  RAM  data  base 
(at  program  initiation)  will  comprise  hard  copy  test 
reports.  This  involves  a  concept  of  operation  in 
which  a  TRADES  management  office  would  undertake 
to  identify  the  hard  copy,  creating  a  definitive  hard 
copy  data  base  which  is  indexed  and  deposited  in  an 
accessible  location,  subject  to  security/need-to-know 
controls  on  distribution.  Such  an  office  could  be 
a  TRADES  management  office  (through  a  separate  Data 
Base  Section),  or  alternatively,  DTIC  or  DLSIE .  DTIC 
has  the  advantage  of  being  the  repository  of  a  large 
holding  of  TECOM  and  OTEA  test  reports. 

Succeeding  efforts  in  the  TRADES  program  should  identify 
holdings  of  hard  copy  and  develop  a  format  for  indexing 
such  reports  for  direct  application  to  TRADES,  and  trans¬ 
late  selected  RAM  information  to  TRADES. 

In  parallel,  TRADOC  should  issue  appropriate  instruc¬ 
tions  to  insure  that  TRADOC  agencies  retain  their  in¬ 
formation,  or  forward/make  it  accessible  to  the  TRADES 
Office  carrying  out  the  development  of  the  source  identi¬ 
fication  module  for  the  TRADES  program.  These  proce¬ 
dures  could  be  made  part  of  a  basic  Army  regulation 
that  establishes  TRADES  and  a  TRADES  management  office 
(see  Recommendations,  Chapter  X  of  this  report). 


A  major  issue  to  be  resolved  common  to  all  ACOs  is  the 
disposition  to  be  made  of  hard  copy  data.  One  approach 
might  be  to  leave  it  in  its  present  physical  location, 
with  provisions  (made  through  military  procedures)  to 
keep  it  from  being  destroyed  until  it  is  no  longer 
useful  for  RAM  analyses.  In  such  a  concept,  the  pro¬ 
ponent,  data  holder  or  generator,  will  develop  an  in¬ 
ventory  and  advise  the  user  (upon  being  queried)  that 
he  has  information  of  interest. 

An  alternative  would  be  to  maintain  a  central  TRADES 
repository  of  all  hard  copy  not  formally  inventoried 
in  major  hard  copy  data  holdings  with  instructions 
issued  for  these  holdings  to  be  forwarded  to  the  cen¬ 
tral  repository. 

The  third  concept,  as  noted,  would  be  to  provide 
current  organized  data  systems  (e.g. ,  DTIC/DLSIE) 
with  the  opportunity  to  index  and  inventory  all 
holdings  not  currently  in  their  files  to  make  them 
available  to  all  potential  RAM  data  users  on  an  as 
required  basis.  DTIC  and/or  DLSIE  would  then  become 
the  central  repository  of  all  hard  copy  historical 
files,  as  well  as  new  data  being  generated. 

On  the  basis  of  the  above,  the  development  of  the 
source  identification  module  would  include  major 
tasks  of: 

1.  Indexing  existing  hard  copy  reports  into  the  TRADES 
source  identification  module 

2.  Providing  adequate  information  for  each  of  the 
source  documents  (hard  copy  reports)  that  will 
provide  the  potential  user  with  adequate  informa¬ 
tion  to  determine  the  usefulness  of  each  test  re¬ 
port  to  his  requirement. 

3.  Extract  key  RAM  data  and  enter  it  into  the  TRADES 
system,  thereby  reducing  response  time  and  narrowing 
the  degree  of  hard  copy  search. 

A  proper  taxonomy  must  be  applied  to  the  hard  copy  to 
identify  the  specific  commodity,  end  item,  major  sys¬ 
tem  or  component  to  which  the  data  are  applicable.  In 
parallel,  information  must  be  provided  as  to  the  EEIs 
included,  environmental  or  geographical  conditions  ap¬ 
plicable,  definition  of  terminology,  etc. 


IMPACT  OF  DRAFT  AR  702-3 


A  review  of  the  most  recent  draft  of  the  proposed 
change  to  AR  702-3  indicates  major  emphasis  on  "oper¬ 
ational  RAM  characteristics" .  The  goal  of  this 
approach  is  to  establish  the  effectiveness  of  the  sys¬ 
tem  in  an  operational  environment.  This  expansion 
requires  incorporation  of  all  personnel  and  support 
system  considerations  in  the  test  programs  and  eval¬ 
uation  in  the  test  report. 

The  implications  of  changes  indicated  in  the  pro¬ 
posed  AR  702-3  are  multi-faceted: 

1.  A  requirement  exists  to  provide  the  RAM  data  base 
with  all  DT  and  OT  incident  reports. 

2.  Present  inherent  reliability  test  results  must  be 
properly  converted  into  operational  RAM  results. 
Therefore,  it  is  necessary  to  reconstruct  the 
total  test  program  (by  incorporation  of  incident 
reports  previously  not  considered  associated  with 
inherent  characteristics  of  the  equipment). 

It  is  not,  however,  feasible  to  rescore  all  old  test 
reports  except  on  an  "as  required"  basis  due  to  the 
enormous  amount  of  effort  involved  in  redefining  and 
scoring  each  test. 

Two  further  requirements  of  the  proposed  AR  702-3 
changes  will  directly  impact  TRADES  with  regard  to 
this  hard  copy  data  base. 

TRADOC  is  assigned  the  responsibility  to  "maintain  a 
central  activity  for  the  proper  statement  and  justifi¬ 
cation  of  RAM  characteristics  in  materiel  requirements 
documents".  This  is  supported  by  TRADOC  development 
of  TRADES. 

TRADES  will  utilize  and  interface  with  the  materiel 
developer  whose  responsibilities  are  set  out  as 
follows : 

"RAM  record  and  audit  trail.  a.  Materiel  developers 
will  establish  an  audit  trail  to  insure  traceability 
of  essential  RAM  effectiveness  and  support  parameters 
at  any  time  during  the  materiel  system's  life  cycle 
in  relation  to  earlier  data  as  well  as  between  pro¬ 
gram  and  contractural  documents". 
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The  manner  in  which  this  requirement  is  to  be  imple¬ 
mented  by  the  various  materiel  developers  will  depend, 
to  a  large  extent,  on  past  practices,  computer  facili¬ 
ties  available,  the  standard  test  programs,  etc. 

On  this  basis,  TRADES  ACOs  must  be  flexible,  have  the 
capacity  to  absorb  the  potential  magnitude  of  reports 
inferred  by  these  requirements,  and  be  able  to  commu¬ 
nicate  with  those  systems  used  by  the  materiel  develop¬ 
ers  to  establish  RAM  audit  trails.  This  is  particu¬ 
larly  important  since  the  results  of  expanded  RAM  con¬ 
siderations  will  not  only  impact  the  using  and  develop 
ing  agencies,  but  will  also  be  of  direct  interest  to 
logistics,  personnel  and  training  activities. 

Of  course,  this  has  much  broader  implications  since 
these  activities  may  require  additional  EEIs  to  satis¬ 
fy  their  needs.  For  example,  personnel  and  training 
may  want  information  on  causes  of  failures,  while 
support  activities  may  be  interested  in  piece/part 
identification.  All  of  these  factors  must  be  consi¬ 
dered  in  assessing  the  potential  future  RAM  informa¬ 
tion  that  must  be  absorbed  or  indexed  to  TRADES. 

DEVELOPMENT  OF  AUTOMATED 
RAM  DATA  REFERENCES 

At  present,  a  certain  amount  of  RAM  data  is  being 
stored  in  automated  data  systems.  However,  with  the 
near  implementation  of  CTDCS  and  the  future  considera¬ 
tion  of  SAMS,  increasingly  larger  portions  of  RAM 
data  will  become  available  from  these  automated  data 
systems.  Accordingly,  each  ACO  to  be  evaluated  must 
recognize  two  potential  conditions  relative  to  auto¬ 
mated  source  data  bases: 

1.  RAM  data  resident  on  a  large-scale  computer  system 
with  interactive  software  capability,  where  a  user 
can  select  certain  data  and  be  provided  an  analyzed 
output  format. 

2.  An  automated  data  base  which  is  principally  a  re¬ 
pository  of  RAM  information  with  little  or  no  inter 
active  software  capability. 

If  condition  1.  prevails,  the  TRADES  interface  module 
should  be  able  to  structure  specific  requirements 
which  can  then  be  processed  on  a  resident  computer. 

The  product  would  be  an  output  report,  either  hard 
copy  mailed  or  on-line  printed  through  a  high-speed 
printer,  of  a  product  directly  usable  by  RAM  engineers 


In  condition  2.  above,  the  overall  TRADES  computer 
system  must  have  provision  for  data  extraction  pro¬ 
grams  and  all  of  the  associated  software  to  process 
the  information  into  usable  form  by  application  of  the 
statistical/analytical  module  in  the  TRADES  computer. 
In  parallel  with  this  would  be  the  requirement  for  the 
TRADES  computer  to  extract  the  necessary  elements  of 
data  from  the  resident  data  bank  and  store  the  infor¬ 
mation  temporarily  during  the  processing.  The  output 
would  be  a  direct  product  of  the  user  via  the  TRADES 
terminal,  and  peripheral  high-speed  printers. 

A  third  alternative  has  possible  merit  when  the  user 
has  a  relatively  large  capacity  computer  available. 
Here,  the  ACO  could  make  provision  to  extract  relevant 
data  fields  from  the  resident  RAM  data  base,  and  pro¬ 
vide  the  data  elements  to  the  user's  computer  facility 
The  user  then  could  develop  his  own  software  package 
for  processing  and  outputting  of  the  data.  Likewise, 
temporary  storage  of  pertinent  information  for  future 
use  is  possible. 

If  a  resident  data  base  is  considered  secure,  provi¬ 
sion  must  then  be  made  to  preclude  the  possibility  of 
such  data  being  "pirated".  Circumstances  which  might 
warrant  such  consideration  would  be:  (1)  if  the  data 
might  be  misinterpreted  by  potential  users,  (2)  dupli¬ 
cation  of  files  is  not  considered  justified  inasmuch 
as  the  original  data  base  will  be  available,  and  (3) 
the  data  might  be  exposed  to  third  parties  who,  for 
security  or  proprietary  reasons,  are  not  considered 
desirable. 

IMPLEMENTATION  SEQUENCE  CONSIDERATIONS 

Each  ACO  will  be  considered  in  view  of  the  life  cycle 
of  TRADES.  They  should  be  capable  of  having  an  initi¬ 
ation  phase,  a  growth  phase,  and  a  maturity  phase. 

The  manner  in  which  the  ACOs  evolve  implies  a  TRADES 
management  team  to  control  the  scope,  content,  and 
phasing  of  operations. 

In  the  initiation  phase,  consideration  could  be  given 
to  starting: 

1.  In  a  given  commodity  area 

2.  Across  all  commodity  areas  for  a  given  life  cycle 
stage  (test  data,  field  data,  etc.) 

3.  A  major  source  or  repository  of  RAM  data  which 
could  involve  one  or  more  commodity  groups. 
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All  of  the  above  approaches  have  their  relative 
merits.  However,  the  most  efficient  and  effective 
approach  appears  to  be  the  third  —  starting  the 
TRADES  program  by  initiating  the  source  identifica¬ 
tion  module  with  an  agency  which  is  a  current  major 
repository  of  RAM  data.  In  this  approach,  all 
phases  and/or  aspects  of  TRADES  could  be  initiated 
on  a  small  scale,  and  expanded  as  necessary  to  in¬ 
clude  all  other  data  sources  on  a  continuing  and 
gradual  basis.  It  also  provides  for  a  gradual  pro¬ 
gram  buildup,  facilitating  debugging  not  only  the 
program,  but  the  overall  TRADES  concept  by  applica¬ 
tion  to  selected  users  on  a  trial  basis. 

When  the  prototype  system  is  operating  smoothly,  the 
repository  of  data  sources  can  be  expanded  selec¬ 
tively  until  the  total  known  RAM  data  source  bases 
have  been  entered. 

During  the  progress  of  full  implementation,  the  sys¬ 
tem  can  be  reviewed  to  establish  any  variability  to 
meet  users'  new  requirements.  At  this  point,  the 
system  can  be  considered  a  fully  mature  system, 
capable  of  meeting  the  total  objectives  of  the  program. 

APPLICATION 

The  description  of  the  TRADES  system  concept  dis¬ 
cussed  above  is  considered  a  requirement  of  capabil¬ 
ities  for  each  of  the  ACOs  to  be  developed  and  evalu¬ 
ated  in  the  remainder  of  this  report.  The  cost  and 
time  implied  by  each  ACO  to  satisfy  the  requirements 
set  forth  herein  constitute  the  major  discriminators 
leading  to  the  preferred  choice. 

In  what  follows,  we  consider  that  TRADES  is  comprised 
of  a  functional  element  and  a  data  processing  element. 
Consideration  of  the  alternative  ACOs  makes  it  clear 
that  the  potentials  of  MTD,  PFDB,  ADPE  and  Stand-Alone 
Systems  must  concern  themselves  with  both  the  data 
processing  function  and  the  functional  responsibilities. 
Therefore,  it  is  appropriate  to  describe  the  overall 
TRADES  in  these  areas  which  are  clearly  inferable 
from  the  SRD  (Part  III)  before  proceeding  to  the  des¬ 
cription  discussion  of  the  automation  alternatives. 

TRADES  is  seen  as  comprising  the  functional  integration 
of  source  identification,  a  repository  of  standardized 
information  in  the  quick  response  module,  a  capability 
to  rapidly  manipulate  any  data  obtained,  and  a 
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technique  for  accessing  automated  data  bases.  The 
entirety  is  unified  by  a  management  module  which  es¬ 
tablishes  the  strategy  of  TRADES. 

Functional  Element  Staffing 

In  order  to  carry  out  the  TRADES  function,  the  func¬ 
tional  element  is  common  to  all  alternatives.  We  see 
the  functional  element  as  follows: 

1.  TRADES  system  management.  This  entails  responsi¬ 
bilities  relating  to  the  establishment  of  the 
strategy  for  directing  the  system,  relative  empha¬ 
sis,  development  of  "where  TRADES  must  go"  to  be 
of  maximum  service. 

2.  Methodological  and  analysis  support.  This  function 
relates  to  being  able  to  make  the  maximum  legita- 
mate  and  proper  inferences  from  the  data  and  to 
develop  the  techniques  which  are  necessary  for  this 
purpose.  Further  responsibilities  are  to  assist 
the  respective  users  and  effect  a  proper  standard¬ 
ization  among  the  methods  of  the  respective  users.* 

3.  Source  and  user  services.  This  area  has  to  do  with 
source/user  services,  i.e.,  the  association  of  the 
user  inquiry  with  the  proper  source.  It  is  too  much 
to  expect  that  the  entire  operation  will  not  require 
human  intervention.  This  function  has  been  called 
in  other  various  times  and  places  -  "customer  ser¬ 
vice".  It  is  the  place  where  the  TRADES  system 
utilizes  humans  to  support  inquiries  and  data 
searches  which  are  not  readily  available  in  the  data 
source  module. 


♦This  is  a  major  by-product  of  the  unification  which  is  accom¬ 
plished  through  TRADES.  By  standardizing  the  statistics  and 
bringing  them  uniformly  to  the  best  possible  estimate  per¬ 
mitted  by  the  data,  the  defensibility  of  the  TRADOC  product 
is  thereby  enhanced. 


The  following  is  an  estimated  functional  manning 

which  applies  to  all  alternatives:* 

1.  TRADES  System  Manager  -  1  Supervisory  General 
Engineer  (RAM),  GS-13.  Qualifications  require  a 
broad-based  understanding  of  TRADES,  RAM  method¬ 
ology,  the  Army  and  its  organization.  Probable 
educational  background  implies  significant  formal 
training  in  statistics/statistical  methodology. 
Approximately  six  to  10  years  of  government 
experience,  system  management  of  at  least  one 
automated  data  system,  or  significant  system  ex¬ 
perience  in  the  planning  and  organization  of  such 
systems. 

2.  Methodology  and  Analysis  Support  -  2  Analysts/Stat¬ 
isticians,  GS-13.  These  personnel  are  primarily 
concerned  with  RAM  methodology.  A  Masters  Degree 
or  better  is  recommended  in  Mathematics/Statistics, 
and  preferably  with  a  minor  or  equivalent  in  Physi¬ 
cal  Science  or  Engineering.  Also  requires  three  to 
six  years  of  system  analysis  involving  inferences 
from  data  and  an  ability  to  handle  computers. 

3.  Source  and  User  Services  -  1  Computer  Specialist, 

GS-12 ,  and  1  General  Engineer  (RAM),  GS-11.  Posi¬ 
tions  require  a  Bachelor  Degree,  three  years  of  ex¬ 
perience  and  analysis  background. 

4.  One  Clerk  Typist,  GS-04.  Functions  include  some 
data  entry,  and  should  be  a  "career  progression" 
type  job.  Work  level  may  ultimately  justify  two 
personnel  in  this  area. 

In  all  cases,  it  is  envisioned  that  the  functional 
personnel  would  be  located  in  TRADOC  integrating  cen¬ 
ters  and  schools,  test  boards,  and  a  coordinating 
branch  in  the  RAM/ILS  Division  of  the  Materiel  Systems 
Directorate 


Data  Processing  Element  Staffin 


The  automation  function  should  consist  of  the  services 
of  Senior  Programmers,  GS-12,  for  programming  changes 
and  special  requirements  generated  by  the  RAM  analysis/ 
methods  support.  This  would  also  include  programming 
of  special  requests  developed  by  the  source/user  ser¬ 
vices  personnel  as  well  as  methodological  and  analysis 
section  of  the  functional  element. 

*  This  does  not  consider  the  personnel  and  funding  resources 
required  in  the  TRADOC  integrating  centers,  test  boards, 
schools,  or  other  TRADOC  supporting  elements. 


Depending  on  the  degree  of  sharing  service  with  other 
activities,  the  automation  function  will  require  an 
operator,  GS-05,  to  operate  the  equipment  for  one 
shift. 

The  full  or  part-time  services  of  a  key  punch  operator, 
GS-04,  is  required  for  the  entry  of  new  data  as  it  be¬ 
comes  available. 

The  data  processing  element  would  be  assigned  to  the 
Computer  Support  Division  of  the  Operations  Analysis 
Directorate  and  absorbed  as  an  additional  workload 
on  their  existing  staff.  For  purposes  of  this  anal¬ 
ysis,  these  personnel  are  not  considered  as  additional 
staffing  requirements  chargeable  to  TRADES. 

A  third  major  function  is  identifiable.  This  would 
be  the  area  of  computer  management,  which  concerns 
itself  with  computer  purchasing,  services,  maintenance 
contracts,  disposal  of  unneeded  equipment,  utilization 
reporting,  economic  analyses,  and  ADP  budgeting.  This 
is  an  inherent  function  of  the  Operations  Analysis  Di¬ 
rectorate,  and  the  impact  of  TRADES  would  be  approxi¬ 
mately  one-half  man-year  of  management  effort. 

TRADOC  School  RAM  Office  Staffing 

Sufficient  staffing  must  be  available  to  perform  the 
added  workload  presented  by  TRADES.  These  functions 
include,  but  are  not  restricted  to  the  following: 

1.  Provide  assistance  to  the  combat  developer  in  using 
the  system. 

2.  Validate  data  to  be  stored  in  the  Quick  Response 
Module. 

3.  Provide  methodology  and  analysis  support  to  the 
combat  developer. 

4.  Serve  as  an  interface  to  other  users  of  TRADES 
for  RAM  data. 


5.  Provide  assistance  in  obtaining  hard  copy  data 
for  locally  held  RAM  data. 


CHAPTER  III 
EVALUATION  CRITERIA 


GOAL 


This  chapter  discusses  the  criteria  used  to  conduct 
the  evaluation  of  the  ACOs. 


BACKGROUND 


The  evaluation  criteria  were  carefully  selected  and 
incorporated  in  both  the  SWP  and  the  SRD  provided 
by  APJ.  SAG  members  closely  scrutinized  these 
criteria  at  the  SRD  meeting  held  in  August  1981, 
and  adopted  some  changes. 

The  first  change  was  to  break  down  resource  require¬ 
ments  into  two  categories,  Investment  and  Operating. 
The  second  change  added  the  criterion  of  Implementa¬ 
tion  Time  to  the  list  of  EEAs,  which  in  effect,  are 
the  criteria  to  be  used  for  the  evaluation  of  the 
three  ACOs. 

The  updated  EEAs,  including  changes,  are  listed  in 
Table  3-1.  A  discussion  of  each  criterion  is  pro¬ 
vided  in  the  remainder  of  the  chapter. 


EEAs 

A  brief  discussion  of  the  EEAs  and  their  relationship 
to  TRADES  was  provided  in  Chapter  VI  of  the  SRD. 

They  are  summarized  here  for  convenience. 

Responsiveness  to  TRADOC 
User  Requirements 

The  TRADES  functional  requirements  are  expressed  in 
terms  of : 

1.  Turnaround  Time  (TAT)  for  RAM  data 

2.  Level  of  RAM  data  required 

3.  RAM  data  form 

4.  Statistical/analytical  manipulation  of  RAM  data 

5.  Application  of  standard  factors 

The  same  responsiveness  requirements  will  be  provided 
by  each  ACO.  The  cost  areas  impacted  by  this  EEA  are 
primarily  in  the  hardware  costs  associated  with  the 
provision  of  the  RAM  data  needed  within  the  time  and 
detail  established  in  Chapter  VI  of  the  SRD. 
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1.  Responsiveness  to  TRADOC  user 

requirements 

2.  Accessibility  to  proponents 

3.  Essential  Elements  of  Information 

4.  Flexibility  (batch  vs  interactive) 

5.  Integration  with  other  systems 

6.  Backup  capability 

7.  Growth  potential 

8.  Quality  control 

9.  Security  -  software  and  data  base 

10.  Implementation  time 

11.  Resource  requirements: 

-  Investment 

-  Operating 


Accessibility  to  Proponents 


The  use  and  availability  of  a  remote  terminal  is 
assumed  to  be  required  for  each  alternative.  There 
is  a  terminal  required  for  each  school,  with  a  vari¬ 
ation  in  terminals  only  with  the  LOGCEN,  based  on 
the  alternative  being  considered.  For  example,  there 
would  be  fewer  terminals  required  in  the  Materiel 
Systems  Directorate  if  the  primary  computer  were  lo¬ 
cated  in  that  directorate.  Primary  impact  of  this 
EEA  is  on  hardware  costs. 

Essential  Elements  of 
RAM  Information 


The  nine  most  frequently  required  EEIs  identified  in 
the  SRD  will  be  considered  a  baseline  to  the  system: 


1.  Mean  Time  between  Failure  (MTBF) 

2.  Mean  Time  between  Operational  Mission  Failures  (MTBOMF) 

3.  Mean  Time  between  Unscheduled  Maintenance  Actions 


(MTBUMA) 

4.  Probability  of  mission  success 

5.  Operational  Availability 

6.  Utilization  Rates 

7.  Mean  Time  to  Repair  (MTTR) 

8.  Maintenance  Ratio  (MR) 

9.  Administrative  Logistic  downtime 


Flexibility 

This  discussion  of  flexibility  applies  only  to  system 
hardware  requirements.  The  topics  of  operational 
flexibility  and  growth  potential  to  include  EEI 
changes,  scope  and  depth  of  coverage,  accessibility, 
etc.  are  discussed  in  conjunction  with  each  of  the 
EEAs « 


The  wide  variety  of  TRADES  requirements  makes  it  man¬ 
datory  to  have  an  interactive  capability  between  the 
user  and  TRADES,  and  also  with  other  systems,  when 
this  is  possible.  Therefore,  batch  processing  is  con¬ 
sidered  to  be  a  method  of  processing  for  routine  file 
update  and  management  information.  The  major  impacts 
of  this  requirement  will  be  on  hardware  and  training 
costs . 
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it’ 


All  ACOs  meet  this  capability  because  an  essential 
function  of  TRADES  is  to  provide  an  interface  and 
integration  capability  with  other  automated  systems. 
Primary  impact  is  on  Resources  EEA. 

Backup  Capability 

The  backup  capability  is  provided  through  two  means: 

1.  A  TRADES  office 

2.  Use  of  default  values. 

The  impact  is  both  on  hardware  costs  and  personnel 
(major  contributors  of  the  Resources  EEA),  and  these 
were  examined  accordingly. 

Growth  Potential 

The  requirement  for  TRADES  to  assimilate  information 
on  more  systems  and  in  greater  detail,  as  well  as 
growth  in  an  increasing  number  and  variety  of  soft¬ 
ware  packages,  is  clearly  articulated  in  the  SRD. 

The  impacts  of  this  area  include  potential  software 
and  hardware  considerations,  as  well  as  personnel 
implications.  Growth  potential  includes  the  ability 
to: 

1.  Absorb  more  and  different  EEIs 

2.  Process  to  piece/part  level,  if  required 

3.  Be  able  to  process  information  from  future 
standard  Army  data  systems. 

Quality  Control 

A  vital  requirement  of  TRADES  is  to  insure  confidence 
in  processed  information.  This  can  be  accomplished 
in  a  variety  or  combination  of  ways: 

1.  Verification  of  test  results 

2.  Verification  of  data 

3.  Parametric  design  check  features 

4.  Use  of  trained  personnel 


Quality  control  of  TRADES  can  be  maintained  by: 

1.  Excellent  feedback  of  information  from  the  user 
to  verify  satisfaction  of  his  request 

2.  Internal  checking  and  auditing,  as  well  as  test 
programs,  to  insure  that  minipulations  do,  in 
fact,  work  as  advertised. 


3.  Control  (designated)  of  access  to  different 
sectors  of  information,  so  that  no  one  can 
change  data  in  the  Quick  Response  Module  or 
the  programs  if  not  previously  authorized. 

From  this  list,  it  can  be  seen  that  all  areas  of  re¬ 
source  requirements  are  affected. 

Security  of  Software 
and  Data  Base 

Techniques  to  provide  security  to  TRADES  includes 
personnel,  hardware,  and  software  controls.  There¬ 
fore,  all  ACOs  assumed  full  use  would  be  made  of 
secure  lines,  encipherment  (as  required),  and  scramb¬ 
ling,  as  described  in  the  SRD. 

Implementation  Time 

The  ACOs  have  a  variable  implementation  time.  For 
example,  it  can  be  assumed  that  under  the  PFDB  options, 
development  of  TRADES  would  parallel  the  development 
time  for  PFDB.  In  comparison,  work  could  begin  very 
quickly  to  modify  the  MTD. 

Resource  Requirements 

The  resources  required  for  the  implementation  of  the 
ACOs  will  be  a  key  measure  of  the  advantages  of  one 
system  over  the  others.  The  resources  are  categor¬ 
ized  by  software,  hardware,  and  personnel  require¬ 
ments.  Where  appropriate,  investment  and  operating 
costs  will  be  shown. 

Hardware 


Hardware  costs  will  be  determined  from  currently 
available  items  from  commercial/GSA  sources,  using 
normal  purchase  price  and  maintenance  contracts. 

Costs  are  considered  for  the  essential  components 
(terminals,  disk  or  tape  drives,  storage  devices, 
security  devices,  communications  equipment,  printers, 
and  central  processing  unit). 


Sof  tware 


Software  costs  are  determined  primarily  by  the  costs 
of  programming,  where  appropriate.  However,  where 
separately  identifiable  (e.g.,  for  the  purchase  of  a 
modern  data  base  management  system  or  analysis  pro¬ 
grams),  these  costs  will  be  portrayed. 


Facilities 


These  costs  are  estimated  where  it  is  anticipated 
that  a  major  modification  to  existing  or  planned 
facilities  is  required. 

Personnel 

These  costs  are  based  on  developmental,  training, 
and  operational  requirements,  within  broad  estimates. 
They  are  based  on  general  planning  factors  set  forth 
in  TB  18-21. 

SUMMARY 


The  methodology  portrayed  in  this  chapter  provides  a 
process  for  selection  of  the  recommended  course  of 
action.  Salient  features  have  been  included,  which 
form  a  baseline  for  additions  or  deletions  on  a 
selective  basis,  and  for  weighting  the  EEAs ,  as 
desired. 


CHAPTER  IV 

PLANNING  FACTORS  DATA  BASE  ( PFDB )  ALTERNATIVE 


GENERAL 

The  objective  of  the  Planning  Factors  Data  Base 
(PFDB)  System  is  to  provide  an  efficient  and  accurate 
means  of  storing,  processing  and  disseminating 
approved  logistics  planning  factors  and  relating 
data  from  a  central  source  for  use  in  joint/ 
unilateral  service  planning,  force  development, 
logistics  studies,  and  reference  publications  such 
as  FM  101-10-1.  These  planning  factors  encompass 
all  classes  of  supply,  maintenance,  transportation, 
services,  and  facilities. 

The  PFDB  is  a  proposed  system  which  is  being  developed 
by  the  Planning  Factors  Management  Division  (PFMD) 
of  the  Operational  Analysis  Directorate  (OAD)  at  the 
LOGC.  The  Detailed  Functional  System  Requirements 
(DFSR)  is  anticipated  to  be  completed  in  the  fall 
of  1981  and  fully  operational  by  January  1984.  This 
system  is  described  in  more  detail  in  Chapter  V  of  the 
System  Requirements  Definition  (SRD)  report.  The 
PFMD  will  interface  with  many  organizations  through¬ 
out  the  Army  and  with  some  organizations  of  other 
services.  The  following  organizations  are  candidates 
for  direct  output  report  dissemination  through  tele¬ 
communications:  USAREUR,  FORSCOM,  all  Army  corps, 

CAA,  MTMC,  ADMINCEN,  Aviation  School,  Quartermaster 
School,  and  the  Transportation  School. 

The  PFDB  may  be  characterized  as  a  partially  dis¬ 
tributed  automated  processing  system  since  it  is 
configured  with  a  dedicated  mini-computer  (estimated 
to  be  the  size  of  a  VAX  11/780)  linked  to  a  mainframe 
(eg.  DPFO's  UNIVAC  1100)  both  accessible  by  a  number 
of  interactive  as  well  as  batch  terminals.  Central 
management  and  control  of  the  planning  factors  system 
will  be  accomplished  by  the  PFMD  through  the  mini¬ 
computer.  A  simplified  diagram  of  the  PFDB  system 
configuration  is  shown  in  Figure  4-1. 
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USERS 


Figure  4-1.  Generic  PFDB  System  Configuration 

Sources  of  data  are  anticipated  to  be  from  several 
existing  systems.  A  list  of  these  are  provided 
below: 

1.  Asset  Composition  System  (ACS) 

2.  Structure  &  Composition  System  (SACS) 

3.  The  Army  authorization  Document  System 

4.  TOE  Master  Files 

5.  COMPASS 

6.  MTD  File 

7 .  MACRIT 

8 .  AMDF 

9 .  LSAR 

10.  SB710-1-1 

11.  LIF 

12.  DA  Standard  Equipment  File 

13.  SB  700-20 

14.  Sample  Data  Collection  (SDC)  File 

The  MTD  File  will  be  integrated  into  the  Planning 
Factors  Data  Base  System  in  both  hardware  and 
software. 

The  future  PFDB  system  software  will  involve  four 
major  functions  feeding  the  planning  factors  data 
base.  These  are  collection,  analysis/development, 
and  validation  and  storage.  Likewise,  four  essential 
functions  are  involved  in  providing  credible  output 
from  the  data  base  to  users.  These  are  retrieval, 
development/aggregation,  validation  and  dissemination 
A  management  function  is  required  to  assure  effective 
and  efficient  operation  of  the  other  functions.  The 
overall  system  structure  is  depicted  in  Figure  4-2. 


The  PFDB  functions  lie  in  five  general  areas: 
data  maintenance,  user  access,  management  information 
support,  data  base  administration,  and  software 
maintenance . 

Four  of  the  five  major  software  processes  contributing 
to  the  production  use  of  the  PFDB  (data  maintenance, 
user  access,  management  information,  and  data  base 
administration),  will  each  have  a  module  associated 
with  the  process.  Each  of  these  modules  depends  on  a 
general  data  base  management  system. 


4-2.  Future  PFDB  System  Structure  for  Software 


Figure  4-3  shows  the  TRADES  Alternative  Concept  of 
Operation  (ACO)  using  the  PFDB  System.  Significant 
characteristics  of  this  TRADES  ACO  are: 

1.  TRADES  will  be  able  to  piggy-back  onto  the 
PFDB  System  which  is  already  into  the  develop¬ 
ment  cycle  (with  DFSR  to  be  completed  shortly, 
regulation  approved,  and  concept  of  operation 
formalized) . 

2.  Development  of  software  for  both  TRADES  and 
PFMD  would  be  accomplished  concurrently  to 
take  advantage  of  commonalities  in  software, 
hardware,  and  data  bases. 


RAM/ I LS  DIVISION 


Figure  4-3.  TRADES  Alternative  Concept 

of  Operation  (ACO)  Using  PFDB  System 


However,  the  software  for  TRADES  and  PFDB 
will  be  designed  for  stand-alone  operation. 

3.  Interoperability  capabilities  between  TRADES 
and  PFDB  would  be  facilitated. 

4.  Interface  development  with  users  common  to 
both  PFDB  and  TRADES  would  be  accomplished 
once  instead  of  twice. 

5.  A  single  facility  for  both  TRADES  and  PFDB 
would  simplify  procedures  for  users  and  inputs 
from  various  sources  (some  common). 

Several  assumptions  were  made  in  order  for  the  ACO 

to  meet  all  of  the  TRADES  requirements.  These  are 

described  below: 

1.  The  TRADOC  DPFO  will  accommodate  a  dedicated 
line  from  the  TRADES  PFDB  mini-computer  for 
both  secure  and  unclassified  processing. 

2.  The  TRADOC  DPFO  will  accommodate  interactive 
demands  (less  than  160  per  day),  and  batch  . 
jobs  with  turnaround  in  less  than  2  weeks  from 
a  service  standpoint. 

3.  TRADES  and  PFDB  software  will  be  developed 
using  the  same  language. 

4.  Future  development  of  TRADES  and  PFDB  will  be 
managed  jointly  between  the  Materiel  Systems 
Directorate  and  Operations  Analysis  Directorate 
at  the  LOGC. 

5.  A  secure  area  and  appropriate  facilities  will 
be  provided  for  TRADES  and  PFDB  classified 
terminals  and  data  storage. 

ORGANIZATIONAL  CHARACTERISTICS 


Contained  in  this  section  will  be  a  general  descrip¬ 
tion  of  the  organizations  required  to  operate  and 
maintain  this  TRADES-PFDB  Alternative  Concept  of 
Operation  (ACO)  at  the  LOGC. 


LOGC  TRADES  Organization:  RAM/ILS  Division 


To  effectively  operate  and  maintain  the  computer  as¬ 
pects  of  this  TRADES-PFDB  ACO  with  respect  to  the 
stated  requirements  in  the  SRD.  The  six  additional 
functional  personnel  discussed  in  Chapter  II  will  be 
required  in  the  TRADES  office  within  the  RAM/ILS 
Division  of  the  Materiel  Systems  Directorate  and  one 
(1)  additional  Computer  Specialist/Data  Base  Admin¬ 
istrator  to  the  Planning  Factors  Management  Division*. 

*  This  does  not  consider  the  personnel  and  funding  resources 
required  in  the  TRADOC  integrating  centers,  test  boards, 
schools  or  other  TRADOC  supporting  elements. 
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rr 


The  functions  of  the  TRADES  office  will  be  to  support 

the  TRADES-MTD  in: 

1.  TRADES  management 

2.  Customer  service 

3.  TRADES  development  and  enhancement 

4.  RAM  analysis 

The  additional  TRADES  Specialist  assigned  to  PFMD  will: 

1.  Coordinate  developments  and  enhancements  to 
TRADES  and  PFDB. 

2.  Coordinate  TRADES  customer  service  requirements 
between  the  TRADES  office,  PFMD,  DPFO,  and  the 
LOGC  Computing  Center. 

3.  Monitor  and  manage  jobs  submitted  to  LOGC 
Computing  Center  (PFDB-TRADES  mini-computer) 
and  DPFO. 

4.  Participate  in  TRADES  enhancement  and  development 
studies. 


External  Organizational  Interfaces 


Schools  and  centers  will  be  primary  functional  cus¬ 
tomers /users  of  the  TRADES  system,  and  also  serve  a 
role  as  proponent  for  entries  affecting  systems  for 
which  they  are  responsible.  In  some  cases,  workload 
may  justify  the  assignment  of  additional  RAM  person¬ 
nel.  Interface  between  these  organizations  and  the 
LOGC  is  absolutely  vital,  to  ensure  that  requirements 
(job  runs,  interactive  service,  protocol,  storage  re¬ 
quirements)  are  met,  and  files  reviewed  and  updated 
on  a  timely  basis. 


Other  organizational  interfaces  may  include  data 
sources  (DARCOM  activities,  TRADOC  boards  and  other 
test  activities),  as  well  as  other  users  of  TRADES, 
such  as  HQ,  DA  Logistics  Evaluation  Agency  (upon 
occasion).  These  external  interfaces  must  be  coordi¬ 
nated  by  the  TRADES  Management  Branch  and  performed 
by  the  computer  systems  of  the  respective  agencies 
wherever  possible. 


The  functions  of  the  TRADES  personnel  in  the  RAM  offices 
of  the  TRADOC  schools  will  be  to  support  TRADES  in: 

1.  Update  of  the  Quick  Response  Module  data. 

2.  Customer  Service 

3.  RAM  Analysis. 


PROCEDURAL  CHARACTERISTICS 


The  users  of  this  TRADES-PFDB  Alternative  can  be 
categorized  as  those  with  unclassified  computer 
interface  capability  (e.g.,  have  interactive 
terminals  with  acoustic  coupler),  those  with  secure 
access,  and  those  with  no  terminals  available. 

Those  users  with  computer  terminal  and  acoustic 
coupler  equipment  can  access  TRADES  directly  on 
the  PFDB-TRADES  mini-computer  located  in  the  LOGC 
Computing  Center  or  UNIVAC  1100/82  time  sharing 
mainframe  at  DPFO,  Fort  Leavenworth  via  normal 
telephone  lines  (Telephone  numbers  will  be  assigned 
by  DPFO  and  the  LOGC  Computing  Center  to  appropriate 
computer  access  ports). 

Normal  "log  in"  procedures  to  access  the  mini-computer 
or  the  mainframe  will  be  used  to  interact  with  TRADES. 

For  users  who  have  computer  terminals  and  secure 
link  capability,  access  is  gained  with  procedures 
similar  to  those  described  above  for  unclassified 
users. 

Lastly,  for  those  users  who  do  not  have  terminals 
(estimated  to  be  about  50%  in  SRD),  solicitation 
for  RAM  data  and  analysis  products  will  be  made  by 
mail  or  telephone  calls  to  the  TRADES  office.  The 
additional  staff  recommended  previously  will  be 
sufficient  to  handle  the  initial  load  (growth  in 
number  of  users  in  the  future  may  necessitate 
additional  personnel). 

An  additional  function  to  be  performed  by  the 
TRADES  office  will  be  the  development  of  new  data 
and  provision  of  customer  service.  Analysts  will 
assist  in  the  validation  of  new  or  updated  RAM 
data  on  a  continuous  and  controlled  basis  before 
entry  into  the  TRADES  and  provide  customers  (with 
or  without  terminals)  with  periodic  reports  of 
changes  or  modifications  to  TRADES  in  terms  of 
data,  hardware,  software,  management,  procedures, 
and  regulations. 

Procedural  control  of  classified  data  must  be 
accomplished  in  accordance  with  appropriate 
regulations  and  restrictions. 

It  is  recommended  that  a  TRADES  Army  Regulation 
document  and  TRADES  Users/Programmers  Guide  be 
developed  for  management  of  the  program. 


ADPE  CONFIGURATION 
Hardware 

The  Automatic  Data  Processing  Equipment  (ADPE)  and 
hardware  used  in  this  TRADES  concept  configuration 
consist  of  the  following: 

1.  Two  time  sharing  computer  mainframes  with  large 
mass  storage.  Data  Base  Management  System 
(DBMS),  communications  ports,  etc.,  one  for 
unclassified  and  the  other  for  classified  data 
processing . 

2.  A  micro-computer  with  disk  storage  or  interactive 
terminals,  with  communications  capability 
(several  terminals  may  be  multiplexed  off  a 
single  telecommunications  link  to  a  host  computer) 

3.  Classified  and  unclassified  communications 
interface  equipment  between  users,  mini-computer 
and  mainframe. 

4.  A  mini-computer  with  interactive  capability 
having  its  own  DBMS  batch  terminal .  public  and 
private  disk  packs,  a  nine-track  tape  drive,  and 
communications  equipment,  so  that  it  can  operate 
independently. 

5.  Dedicated  link  between  the  PFDB-TRADES  mini¬ 
computer  and  UNIVAC  1100/82  machines. 

Communication  requirements  include  the  communications 
between  the  two  sites  and  between  external  users  and 
PFDB.  Communications  between  the  two  sites  (LOGC 
and  DPFO)  will  be  by  direct  communication  link  and 
by  magnetic  tape,  magnetic  disk  and  punched  cards. 

It  is  estimated  that  2  to  5  telephone  extensions  will 
be  needed  for  interactive  computer  transmission. 
Several  I/O  devices  will  be  required  at  PFMD. 

Figure  4- 4  shows  an  overview  of  the  hardware  required 
in  this  configuration. 

Software 

The  software  to  be  developed  for  this  TRADES  concept 
will  consist  of  the  following  five  software  modules: 

1 .  Management  Module 

2.  Source  Identification  Module 

3.  Quick  Response  Module 

4.  Statistics/Analysis  Module 

5.  Interface  Module 


HARDWARE 


CONCEPT  CHARACTERISTICS 


Mainframe  Time  share  with  DPFO  large  mainframe  computer  with 

batch  and  interactive  capability  through  terminals. 


Mini -computer  Utilizes  a  mini -computer  with  multiple  terminals 

capability  to  handle  processing  and  report  dis¬ 
semination.  Estimated  need  of  2-4  MB  of  local 
_ memory. _ 

Line  Printer  Use  high  speed  line(600  LPM)printer  located  at 

LOGO  Computing  Center. 


Card  Reader  Use  50-200  CPM  Card  Reader  located  at  LOGC 

Computing  Center. 


Tape  Drives  Use  9-Track  tape  drives  located  at  LOGC  Computing 

Center. 


Disk  Drives  Use  DPFOs  and  LOGC  disk  drives  and  disks  for  support 

of  TRADES.  Minimum  of  90  MB  storage  capability. 


Micro-Computers  or  Use  micro-computers  or  any  interactive  terminal  with 

Interactive  Terminals  communications  equipment  for  interactive  operations. 


Security  Equipment  Use  KG  device  for  I/O  transactions. 


Communications  Use  a  4800  Baud  dedicated  line  from  the  TRADES 

Equipment  office  via  the  PFDB-TRADE  mini-computer  office 

to  DPFO  and  other  computer  ports  for  interactive 
processing. 


Multiplexers 


A  synchronous,  minimum  of  light  communications  lines 


Modems  Modems  and  cables  as  necessary  for  multiplexer  re¬ 

quirement.  Also  needed  with  each  terminal /mini¬ 
computer 


Graphics  Terminals  Graphics  terminals,  preferably  color  system,  for 

requirements  and  performance  charting. 


Figure  4-4.  Hardware  Overview 


These  modules  and  overall  software  systems  design 
are  described  in  detail  in  the  methodology  section 
of  this  report.  These  modules  will  control  data 
input,  output,  retrieval,  update,  manipulation,  and 
changes.  For  this  alternative,  the  TRADES  software 
will  be  developed  in  conjunction  with  and  in  the  same 
language  as  that  specified  for  PFDB.  However,  TRADES 
will  be  developed  as  a  stand-alone  system,  i.e.,  the 
software  systems  will  be  separate. 

This  concept  requires  a  DBMS  to  be  resident  on 
the  mainframe  as  well  as  on  the  mini-computer. 


CHAPTER  V 


MAINTENANCE  TASK  DEMAND  ( MTD )  FILE  ALTERNATIVE 


GENERAL 


The  objectives  of  the  design  of  the  TRADES  alterna¬ 
tive  incorporating  the  Maintenance  Task  Demand  (MTD) 
File  System  (TRADES-MTD  Alternative)  are  to: 

1.  Meet  the  requirements  for  TRADES  as  delineated 
in  the  System  Requirement  Descriptions  (SRD). 

2.  Utilize  to  the  extent  possible  a  system  which 
has  already  been  designed,  developed,  tested 
and  implemented. 

3.  Avoid  long  development  lead  times  and  excessive 
costs  for  TRADES. 

The  MTD  File  System  is  operational  and  is  managed 
by  the  Technical  Design  and  Validation  Branch  of 
the  Planning  Factors  Management  Division  (PFMD)  at 
the  LOGC.  This  system  (described  in  Chapter  V  of 
the  SRD)  currently  runs  on  the  UNIVAC  1100/821  at 
the  TRADOC  Data  Processing  Field  Office  (DPFO) 
located  at  Fort  Leavenworth,  Kansas.  It  has  both 
user  interactive  and  batch  processing  capability. 

The  System  2000  Data  Base  Management  System  (DBMS) 
for  data  storage,  manipulation,  and  retrieval  is  also 
available  on  the  system.  A  simplified  diagram  of  the 
MTD  File  System  organization  is  shown  in  Figure  5-1 


The  MTD  File  System  is  a  stand-alone  system  managed 
by  the  Planning  Factors  Management  Division  (PFMD), 
which  will  eventually  be  integrated  into  PFDB  in 
both  hardware  and  software. 

Figure  5-2  shows  the  TRADES  configurations  using 
the  MTD  File  System.  The  most  significant  con¬ 
sideration  in  this  configuration  is  the  development 
of  the  TRADES  software  which  will  incorporate  the 
MTD  File  System.  The  main  software  pre-processor 
and  post-processor  will  need  to  be  modified  to  fit 
the  TRADES  requirements  in  terms  of  the  management, 
source  identification,  quick  response,  statistical/ 
analytical,  and  interface  modules  described  in  the 
methodology  portion  of  this  report. 

Several  assumptions  were  made  in  order  for  the 
alternative  to  meet  all  of  the  TRADES  requirements. 
These  are  described  as  follows: 

1.  The  TRADOC  DPFO's  computer  system  will  accommo¬ 
date  160  requests  per  day  interactively  or 
batch  with  job  turnaround  in  less  than  2  weeks 
from  a  service  standpoint. 

2.  TRADES  software  will  be  written  in  FORTRAN  IV. 

3.  Mass  storage  capability  at  DPFO  is  sufficient 
for  the  TRADES -MTD  alternative  using  the 
System  2000  DBMS. 

4.  Future  development  and  growth  of  this  alterna¬ 
tive  will  be  addressed  as  part  of  the  PFDB 
development . 

5.  A  secure  area  and  appropriate  facilities  will 
be  provided  by  the  LOGO  for  TRADES  classified 
terminal  and  data  storage. 

ORGANIZATIONAL  CHARACTERISTICS 

Contained  in  this  section  will  be  a  general  descrip 
tion  of  the  organizations  required  to  operate  and 
maintain  this  TRADES-MTD  alternative  at  the  LOGC. 

Internal  TRADES  Organization:  RAM  Directorate 

To  effectively  operate  and  maintain  the  computer 
aspect  of  the  TRADES-MTD  alternative,  it  is  esti¬ 
mated  that  the  six  additional  functional  personnel 
discussed  in  Chapter  II  will  be  required  in  a  TRADES 
office  within  the  RAM/ILS  Division. 


TRADES  USERS 

_ COMMUNICATION  _ 

RAM/ILS  DIVISION  Tr - INTERFACE  EQUIPMENT  DPFO 


The  functions  of  the  TRADES  office  will  be  to  support 

the  TRADES -MTD  in: 

1.  TRADES  Management 

2.  Customer  Service 

3.  TRADES  Development  and  Enhancement 

4.  RAM  Analysis. 

External  Organizational  Interfaces 

Interface  between  the  TRADES  office  and  the  Planning 
Factors  Management  Division  (PFMD)  is  essential  for 
coordinated  development  of  both  the  MTD  File  System 
and  TRADES,  i.e.  any  software  or  hardware  develop¬ 
ments  may  be  mutually  beneficial  for  capabilities 
enhancement.  Further,  interface  between  the  TRADES 
office  and  DPFO  is  required  to  ensure  adequate 
service  and  UNIVAC  support  is  maintained,  and  TRADES 
requirements  (job  runs,  interactive  service,  protocol, 
storage  requirements,  etc.)  are  coordinated. 

The  other  organizational  interfaces  will  include 
the  organizations  (other  LOGC  Directores,  TRADOC 
Schools  and  Centers,  TRADOC  Boards,  and  DARCOM 
activities)  that  interact  with  the  TRADES  either  as 
users  or  sources. 


PROCEDURAL  CHARACTERISTICS 

The  users  of  this  TRADES-MTD  alternative  can  be 
categorized  as  those  with  unclassified  computer 
interface  capability  (e.g.  have  interactive  termi¬ 
nals  with  acoustic  coupler),  those  with  secure 
access  computer  interface  capability,  and  those 
without  any  terminals. 

Those  with  computer  terminal  and  acoustic  coupler 
capability  can  access  TRADES  on  the  mainframe, 
UNIVAC  1100/82,  via  normal  telephone  lines 
(telephone  numbers  will  be  assigned  by  DPFO  to 
appropriate  computer  access  ports).  Normal 
"log  in"  procedures  will  then  be  used  to  interact 
with  TRADES. 

For  users  who  have  computer  terminals  and  secure 
link  capability,  access  is  gained  with  procedures 
similar  to  those  described  above  for  unclassified 
data  users. 


Lastly,  for  those  users  who  do  not  have  terminals 
(estimated  to  be  about  50%  in  SRD)  solicitation  for 
RAM  data  and  analysis  products  will  be  made  by 
mail  or  telephone  calls  to  the  TRADES  office.  The 
additional  staff  recommended  previously  will  be 
sufficient  to  handle  the  initial  load  (growth  in 
number  of  users  in  the  future  may  necessitate 
additional  personnel). 

An  additional  function  to  be  performed  by  the 
TRADES  office  will  be  the  development  of  new  data 
and  provision  of  customer  service.  Analysts  will 
assist  in  the  validation  of  new  or  updated  RAM 
data  on  a  continuous  and  controlled  basis  before 
entry  into  the  TRADES  and  provide  customers  (with 
or  without  terminals)  with  periodic  reports  of 
changes  or  modifications  to  TRADES  in  terms  of 
data,  hardware,  software,  management,  procedures, 
and  regulations. 

Procedural  control  of  classified  data  must  be 
accomplished  in  accordance  with  appropriate 
regulations  and  restrictions. 

It  is  recommended  that  a  TRADES  Army  Regulation 
document  and  TRADES  Users/Programmers  Guide  be 
developed  for  management  of  the  program. 


ADPE  CONFIGURATION 
Hardware 

The  Automatic  Data  Processing  Equipment  (ADPE)  and 
hardware  used  in  this  TRADES  concept  configuration 
consist  of  the  following: 

1.  Two  computer  mainframes  with  large  mass  storage, 
FORTRAN  compiler,  System  2000  DBMS,  communica¬ 
tions  ports,  etc.,  one  for  unclassified  and  the 
other  for  classified  data  processing. 

2.  A  micro-computer  with  disk  storage  or  interactive 
terminal0  with  communications  capability  (several 
terminals  nay  be  multiplexed  off  a  single  tele¬ 
communications  link  to  a  host  computer). 

3.  Classified  and  unclassified  communications 
interface  equipment. 

Figure  5-3  shows  an  overview  of  the  hardware  required 
in  this  configuration. 
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HARDWARE 

CONCEPT  CHARACTERISTICS 

Mainframe 

Time  share  with  large  mainframe  computer  with 
batch  or  interactive  capability  through  terminals. 

Line  Printer 

Use  high  speed  line  600  LPM  printer  located  at 

LOGC  Computing  Center. 

Card  Reader 

Use  50-200  CPM  Cord  Reader  located  at  LOGC 

Computing  Center. 

Tape  Drives 

Use  9-Track  tape  drives  located  at  LOGC  Computing 

Center. 

Disk  Drives 

Use  DPFOs  disk  drives  and  disks  for  support  of 

TRADES. 

Micro-Computers  or 

Interactive 

Terminals 

Use  micro-computers  or  any  interactive  terminal 
with  communications  equipment  for  interactive 
operations . 

Security  Equipment 

Use  KG  device  for  1/0  transactions. 

Communications 

Equipment 

Use  a  4800  Baud  dedicated  line  from  the  TRADES 

office  to  DPF0  and  other  computer  ports  for 
interactive  processing. 

-  _  --------  - 

Figure  5-3.  Hardware  Overview 
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Software 

The  software  to  be  developed  for  this  TRADES  concept 
will  consist  of  the  following  five  software  modules: 

1.  Management  Module 

2.  Source  Identification  Module 

3.  Quick  Response  Module 

4.  Statistical/Analy tical  Module 

5.  Interface  Module 

These  are  described  in  detail  in  the  methodology 
section  of  this  report.  These  modules  will  control 
data  input,  output,  retrieval,  update  and  changes. 
For  this  alternative,  the  TRADES  software  will  be 
written  in  FORTRAN  and  incorporate,  to  the  extent 
feasible,  the  software  already  developed  for  the 
MTD  File  System.  It  is  estimated  that  the  MTD  File 
System  software  will  comprise  40%-60%  of  the  TRADES 
software.  Also,  the  concept  will  utilize  the  System 
2000  DBMS  and  its  data  base  language  for  ad  hoc 
queries  into  the  TRADES  data  base. 


GENERAL 


CHAPTER  VI 

LOGC  ADPE  REQUIREMENTS  STUDY  ACO  ALTERNATIVE 


This  alternative  concept  is  the  same  as  the  Planning 
Factors  Data  Base  (PFDB)  Alternative,  except  that  a 
second  mini-computer  has  been  added  to  the  configura¬ 
tion  . 

The  recommended  ACO  resulting  from  the  LOGC  Automatic 
Data  Processing  Study  is  shown  in  Figure  6-1.  This 
alternative  employing  three  mini-computers  was 
designed  to  support  the  logistics  exercise  (LOGEX), 
PFDB,  and  other  LOGC  workload  by  using  the 
flexibility  of  three  interconnected  mini-computers. 
These  computers  can  accommodate  varying  requirements 
for  LOGEX,  PFDB,  TRADES,  and  other  special  systems. 
This  combination  provides  enhanced  responsivenss 
and  reliability  in  supporting  Logistics  Center  data 
processing.  Phase  I  of  the  LOGC  ADPE  Requirements 
Study  has  been  completed  and  approved.  Phase  II, 
to  occur  in  the  near  future,  will  result  in  Detailed 
Functional  System  Requirements  (DFSR)  to  begin  the 
formal  AR  18-1  development  cycle. 


Figure  6-2  shows  the  TRADES  using  the  LOGC  ADPE  Re¬ 
quirements  Study  Concept.  This  TRADES  ACO  takes 
advantage  of  the  LOGEX  mini-computer  shown  in  Figure 
6-1. 


The  LOGEX  mini-computer  to  be  used  principally  for 
batch  processing,  will  be  located  in  a  secure 
environment  so  that  it  may  be  connected  to  either 
the  secure  or  unsecure  machines.  When  the  central 
machine  is  connected  to  the  unsecure  mini-computer, 
users  can  submit  unclassified  jobs  through  the 
local  batch  terminal  or  through  the  unsecure 
communications  mini-computer.  When  this  mini¬ 
computer  is  connected  to  the  secure  PFDB-TRADES  mini¬ 
computer,  classified  processing  can  occur  in  a 
similar  manner.  During  normal  operation,  the 
central  machine  will  process  unclassified  work  and 
classified  batch  jobs  will  be  routed  to  remote 
sites  (e.g.,  DPFO)  or  queued  for  later  processing 
locally. 


Figure  6-1.  LOGC  ADPE  Concept 


Figure  6-2.  TRADES  ACO  Using  the  LOGC  ADPE  Concept 


Users  of  the  mini-computer  from  remote  sites  will 
utilize  remote  batch  terminals  or  interactive 
terminals  to  connect  with  the  Fort  Lee.Va.  facility. 
The  communications  equipment  at  the  facility  will 
route  or  queue  jobs  for  the  appropriate  computer 
site.  As  an  emergency  backup  feature,  remote 
users  can  tie  in  directly  to  the  mainframe  computers 
as  necessary. 

During  the  support  of  LOGEX,  the  LOGEX  and  TRADES 
shared  mini-computer  will  be  dedicated  solely  to 
LOGEX.  Two  batch  terminals  and  two  interactive 
terminals  will  be  moved  to  the  area  of  the  logistics 
exercises  and  tie  in  directly  to  the  central 
computer  by  telephone  lines. 

With  this  ACO,  TRADES  will  be  supported  by  two 
mini-computers  locally  at  the  LOGC  giving  more 
flexibility  and  capability  in  terms  of  growth, 
customer  service  and  responsiveness. 

The  Organizational  Characteristics,  Procedural 
Characteristics  and  ADPE  Configu  ation  will  be  the 
same  as  that  described  for  the  Planning  Factor 
Data  Base  ( PFDB )  Alternative* with  the  exception  of 
the  LOGEX  mini-computer  being  added  for  TRADES 
utilization. 


CHAPTER  VII 
STAND-ALONE  TRADES 


GENERAL 


In  this  ACO,  TRADES  is  considered  from  the  viewpoint 
of  a  stand-alone  or  free-standing  system,  i.e.,  in¬ 
dependent  of  other  existing  or  planned  computerized 
systems . 

The  essential  computer  characteristic  required  to 
satisfy  the  TRADES  concept  is  random  access  with  a 
substantial  data  storage  capability.  From  a  manage¬ 
ment  standpoint,  it  is  clearly  desirable  to  minimize 
both  initial  procurement  and  annual  maintenance/ 
operating  costs. 

When  considered  independently  of  the  type  of  computer, 
the  stand-alone  TRADES  concept  could  be  designed  for 
a  large,  modern  main  frame  computer.  However,  cur¬ 
rent  computer  technology  and  state-of-the-art  makes 
several  mini-computers  available  which  might  satisfy 
the  TRADES  requirements.  Thus,  it  is  also  conceiv¬ 
able  to  consider  a  mini-  or  micro-computer  as  a 
"stand-alone"  system  for  accessing,  updating,  and 
maintenance  of  TRADES.  The  major  difference  between 
a  mini-computer  and  a  large  main  frame,  such  as  the 
TRADOC  DPFO  at  Ft.  Leavenworth,  would  be  in  access 
and  processing  times. 

The  large  computer  facility  at  the  DPFO  has  a  much 
faster  internal  processing  time  than  the  mini-computers 
However,  since  the  computer  facility  is  used  primarily 
for  information  search,  internal  operating  speed  of 
mini-computers  is  not  considered  a  significant  factor 
for  TRADES. 

The  main  attractions  of  the  mini-computer  are  modest 
initial  investment  and  annual  maintenance  and  oper¬ 
ating  costs,  together  with  direct  accessibility  by 
TRADES  management  personnel  and  relative  simplicity 
of  operation. 


CENTRALIZED  VS  DISPERSED 
CONFIGURATION 

The  advent  of  the  economical  micro-computer  provides 
an  opportunity  to  consider  dispersed  rather  than  a 
centralized  TRADES  configuration. 

In  the  centralized  configuration,  the  computer  (either 
a  main  frame  or  an  adequate  mini-computer)  would  be 
assigned  to  a  central  activity  with  access  via  inter¬ 
active  terminals  at  each  potential  user.  All  pro¬ 
gramming,  software  development,  file  update,  etc., 
would  be  accomplished  at  a  centralized  agency. 

In  a  dispersed  configuration,  each  potential  user  (or 
selected  activities)  would  be  provided  with  a  business 
micro-computer  facility.  To  facilitate  standardiza¬ 
tion  and  consistency  of  files,  all  software  and  file 
development  would  still  be  accomplished  at  a  central¬ 
ized  activity,  but  distributed  to  the  various  computer 
sites  for  application. 

The  centralized  configuration  has  the  benefit  of  local 
control  of  all  software  and  files  in  TRADES.  Like¬ 
wise,  total  cost  is  minimized  in  that  only  one  system 
is  required  with  adequate  capacity  to  satisfy  all  user 
requirements.  Users  would  be  equipped  with  relatively 
inexpensive  terminals  with  the  capability  of  inter¬ 
acting  not  only  with  the  TRADES  central  computer,  but 
also  with  all  ADP  computer  centers.  The  principal 
disadvantage  might  be  inaccessibility  to  the  TRADES 
computer  in  heavy  workload  hours. 

Personnel  and  funding  required  in  the  TRADOC  integrat¬ 
ing  centers,  test  boards,  schools,  or  other  TRADOC 
supporting  elements  were  not  considered.  This  is  be¬ 
cause  in  each  case,  it  is  envisioned  that  functional 
personnel  would  be  located  in  the  TRADOC  integrating 
centers  and  schools,  test  boards,  and  in  a  coordinat¬ 
ing  branch  in  the  RAM/ILS  division  of  the  Materiel 
Systems  Directorate. 

The  SRD  report  estimates  that  an  average  of  19,500 
requests  would  be  made  per  year  against  a  mature 
TRADES  by  the  total  TRADOC  community.  This  would 
average  75  requests  per  working  day,  or  one  request 
every  six  minutes  (on  an  eight-hour  work  day). 

Based  on  experience  with  such  data  centers,  most 


requests  are  placed  within  the  first  three  to  four 
hours  of  each  work  day.  This  would  most  likely 
overload  the  capability  of  a  single  mini-computer 
unless  it  had  several  access  ports  with  multiplexing 
capabilities . 

A  principal  advantage  of  the  centralized  configura¬ 
tion  would  be  in  cost.  Assuming  that  a  micro¬ 
computer  (complete  with  peripherals)  could  be 
purchased  (in  quantity)  for  $6,000  -  even  a  minimum 
of  40  such  computer  facilities  would  incur  an  ex¬ 
pense  of  $240,000,  which  starts  to  approach  the 
purchase  cost  of  a  high-capacity  modern  technology 
computer.  On  the  other  hand,  the  large  main  frame 
at  the  TRADOC  DPFO,  is  a  sunk  cost,  available  at  no 
cost  to  TRADES. 

Additionally,  many  schools  that  presently  have  a 
one-man  RAM  office  would  require  a  computer  special¬ 
ist/maintenance/programmer  to  support  the  micro¬ 
computer  at  an  annual  direct  operating  cost  of  ap¬ 
proximately  $1.5M-2.0M.  This  computer  specialist 
would  be  used  to  input  information  into  TRADES  files 
relative  to  the  assigned  school/center.  However, 
this  can  be  accomplished  more  efficiently  from  a 
centralized  TRADES  office.  The  main  advantage  of 
the  dispersed  concept  would  be  that  each  TRADOC 
user  would  have  a  direct  access  to  a  computer  to 
assist  him  in  his  efforts.  Recognition  must  be  pro¬ 
vided  to  the  accommodation  by  TRADES  of  microcomputer 
at  the  user  level. 

For  purposes  of  ACO  evaluation,  the  centralized  con¬ 
figuration  shown  in  Figure  7-1  will  be  the  basis  for 
analysis. 

ORGANIZATIONAL  CHARACTERISTICS 

A  general  description  of  the  organizations  required 
to  operate  and  maintain  the  stand-alone  TRADES  al¬ 
ternative  is  presented  in  this  section. 

Internal  TRADES  Organization: 

LOGCEN 

To  effectively  operate  and  maintain  the  stand-alone 
TRADES  alternative,  it  is  estimated  that  the  addi¬ 
tional  six  functional  personnel  discussed  in 
Chapter  II  would  be  required  in  the  RAM/ILS  Divi¬ 
sion. 

Functions  of  the  TRADES  office  will  be: 

1.  TRADES  management 

2.  Customer  service 

3.  TRADES  development  and  enhancement 

4.  RAM  analysis. 
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Schools  &  TSMs 


Figure  7-1.  TRADES  Configuration  Using  Centralized 
Stand-Alone  Computer  Facility 


External  Organizational 
Interfaces 


The  major  external  organizational  interfaces  in 
this  ACO  are  the  ADP  computer  facilities  identified 
as  RAM  data  sources  within  TRADES.  There  will  be  a 
high  level  of  communication  required  between  TRADES 
and  the  facility  which  houses  the  source  data.  Com¬ 
munications  will  be  required  for  either  data  trans¬ 
fer  (where  the  source  computer  facility  cannot  pro¬ 
vide  the  required  analysis),  or  for  coordination  of 
data  analyses,  and  output,  where  the  user  can  take 
advantage  of  software  at  the  computer  facility  for 
direct  output. 

The  source  identification  module  provides  the  key 
to  external  operational  interfaces  required.  Pro¬ 
vision  is  made  within  the  TRADES  interface  module 
as  to  specific  interface  requirements  for  each 
source  identified  that  has  automated  RAM  data  base 
available.  These  references  also  indicate  whether 
source  computer  software  (associated  with  the  spe¬ 
cific  RAM  data  identified)  can  provide  analysis  in 
an  output  format  satisfactory  to  the  user,  or 
whether  a  requirement  exists  to  use  the  statistical/ 
analytical  module  to  process  data  required. 

In  the  latter  case,  external  operational  character¬ 
istics  could  be  directed  to  two  procedures: 

1.  The  computer  at  the  RAM  data  source  can  accept 
a  software  package  for  analysis  of  data  and 
provide  a  predesignated  output  format 

2.  Data  must  be  extracted  from  the  resident  data 
bank,  stored  temporarily  on  a  TRADES  computer, 
and  analyzed  with  the  statistical/analytical 
module  programs. 

PROCEDURAL  CHARACTERISTICS 

Users  of  stand-alone  TRADES  alternatives  may  be 
categorized  as  having  unclassified  computer  inter¬ 
face  capability  (e.g.,  interactive  terminals  with 
acoustic  coupler),  secure  access  computer  interface 
capability,  and  those  without  any  terminals. 


Users  with  computer  terminal  and  acoustic  coupler 
capability  can  access  TRADES  via  normal  telephone 
lines  (numbers  will  be  assigned  by  LOGCEN).  Normal 
"log  in"  procedures  will  then  interact  with  TRADES. 

Users  with  computer  terminals  and  secure  link  ca¬ 
pability,  gain  access  with  procedures  similar  to 
those  for  unclassified  data  users. 

Lastly,  for  users  with  no  terminals  (estimated  to 
be  about  50%  in  SRD) ,  solicitation  for  RAM  data  and 
analysis  products  will  be  by  mail  or  telephone 
calls  to  the  TRADES  office.  The  staff  recommended 
above  will  be  sufficient  to  handle  the  initial  load 
(growth  in  future  users  may  necessitate  additional 
personnel) . 

An  additional  TRADES  office  function  will  be  de¬ 
velopment  of  new  data  and  provision  of  customer 
service.  Analysts  will  assist  in  validation  of  new 
or  updated  RAM  data  on  a  continuous  and  controlled 
basis  before  entry  into  TRADES,  and  provide  cus¬ 
tomers  (with  or  without  terminals)  with  periodic 
reports  of  changes  or  modifications  to  TRADES,  in 
terms  of  data,  hardware,  software,  management,  pro¬ 
cedures,  and  regulations. 

Procedural  control  of  classified  data  must  be  ac¬ 
complished  in  accordance  v/ith  appropriate  regula¬ 
tions  and  restrictions. 

It  is  recommended  that  a  TRADES  regulatory  document 
and  TRADES  Users/Programmers  Guide  be  developed  for 
program  management. 

ADPE  CONFIGURATION 

The  ADP  hardware  utilized  in  this  ACO,  as  shown  in 
Table  7-1,  could  be  either  a  mini-computer  or  a 
large  main  frame  computer  center.  The  system 
should  be  equipped  with  high-speed  line  printers 
and  CRTs. 

Interactive  terminals  will  be  available  (or  will  be 
made  available)  to  all  potential  RAM  users  within 
the  TRADOC  community.  These  terminals  will  be  ca¬ 
pable  of  interactive  communication  with  the  TRADES 
computer . 


7-6 


TABLE  7-1.  HARDWARE  OVERVIEW 


CONCEPT  CONSIDERATIONS 

HARDWARE 

MINI-COMPUTER 

LARGE  MAIN  FRAME 

Main  Frame 

Modern  tech,  mini¬ 
computer  w/random 
access, large  core 

CPU  &  multiple 
process,  feature 

Time-share  w/any  large 
main  frame  computer 
center  w/batch  or 
interactive  capability 
through  terminals 

Line  Printer 

Use  high  speed  line 
potential  TRADC 

printers  at  LOGC  and  at 

C  user  facilities 

Disk  Drives 

Use  high  density 
hard  disk  drives  w/ 
20-30  megabyte 
capacities  or 
better 

Use  disk  drives  and 
disks  available  at 
data  processing 
center 

Interactive  Terminals 

Use  interactive  tenr 
commo  equipment.  Pr 

terminals  to  ot 

-  -- 

inals  with  compatible 
ovide  interactive 

her  TRADOC  users 

----- 

Security  Equipment 

Provide  KG  devices  for  all  I/O  transactions 

.  1  . 

Communications 

1 

Use  dedicated  line  from  RAM/ILS  TRADES 

Branch  to  TRADES  Computer  Center 

The  TRADES  software  will  consist  of  the  five  basic 
modules  described  in  Chapter  II,  plus  a  master  ex¬ 
ecutive  program.  In  this  ACO,  the  TRADES  software 
will  be  developed  as  an  independent  system  design, 
using  the  language  and  logic  best  suited  to  the 
computer  selected  as  the  main  frame. 


CHAPTER  VIII 
ANALYSIS  OF  ALTERNATIVES 


GOAL 


This  chapter  compares  the  ACOs  described  in  Chapters 
IV,  V,  VI  and  VII  above,  using  the  evaluation 
criteria  established  in  Chapter  III.  The  four 
alternatives  are  measured  against  requirements  es¬ 
tablished  in  the  methodology  (Chapter  II).  The 
evaluations  include  a  discussion  of  advantages  and 
disadvantages  of  the  alternatives  as  they  relate  to 
individual  EEAs. 

ACO  COMPARISON  SUMMARY 

The  SRD  developed  specific  requirements  for  TRADES 
utility  to  the  TRADOC  community  (major  issues  raised 
by  these  requirements  were  discussed  in  Chapter  II). 
Table  8-1  presents  a  comparison  of  the  four  ACOs 
against  each  EEA.  These  will  be  reviewed  in  con¬ 
sideration  of  the  differences  among  the  concepts 
portrayed  in  the  preceding  chapters. 

Table  8-2  addresses  the  hardware  requirements  among 
the  ACOs.  The  only  differences  in  hardware  among 
the  ACOs  is  the  alternative  use  of  the  OAD  mini¬ 
computer  (s)  and  the  DPFO  main  frames.  The  MTD  and 
SAMF  ACOs  have  no  OAD  mini-computer  but  use  the 
DPFO  main  frame  as  the  primary  computer.  The  other 
alternatives  use  the  DPFO  main  frame  as  a  backup 
and  share  of  at  least  one  OAD  mini-computer.  The 
ADPE  concept  uses  two  OAD  computers  on  a  shared 
basis,  either  of  the  two  available,  depending  on 
their  individual  workloads. 

The  terminals  identified  for  the  RAM/ILS  Division 
and  the  users  could  be  of  any  type,  as  long  as  they 
are  interactive  and  compatible  with  the  overall 
system  design.  It  is  considered  that  they  might  be 
micro-computers  which  provide  TRADOC  users  with 
computational  facilities  to  assist  their  tasks 
as  RAM  engineers. 


TABLE  8-1.  ACO  RELATIVE  COMPARISONS 
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TABLE  8-1.  AC 0  RELATIVE  COMPARISONS  (Concluded) 


♦Meets  TRADES  requirement  and  equal  capabilities  have  been  provided. 


TABLE  8-2.  ACO  COMPARISON  -  HARDWARE  REQUIREMENTS 


ACO 

RAM/ I LS  DIV. 

AOD 

DPFO 

USERS 

PFDB 

1 -Terminal 

1-Line  Printer 
1-Multiplexer 

1 -Mini -computer 

1 -Terminal 

1-Mul tiplexer 
1-Line  Printer 
1-Tape  Drive 
1-Disk  Drive 

1-Key  Punch 

1-Main  Frame 
(backup) 

1 -Terminal 

1 -Multiplexer 
1-Line  Printer 

MTD 

(Same  as  PFOB) 

(Same  as  PFDB 
less  Mini) 

1 -Terminal  & 
Multiplexer 

1-Main  Frame 

(Same  as  PFDB) 

ADPE 

(Same  as  PFDB) 

(Same  as  PBDB 
+  2nd  Mini) 

(Same  as  PFDB) 

(Same  as  PFDB) 

SAMI 

(Same  as  PFDB) 

(Same  as  PFDB) 

(Same  as  PFDB) 

(Same  as  PFDB) 

SAMF 

(Same  as  PFDB) 

(Same  as  PFDB, 
less  Mini) 

1 -Terminal  & 
Multiplexer 

1-Main  Frame 

(Same  as  PFDB) 

EVALUATION 

Responsiveness 

In  almost  all  areas,  there  are  no  significant  dif¬ 
ferences  among  the  ACOs.  For  example,  actual 
processing  time  on  large-scale  computers  of  the 
UNIVAC  1100  series  would  be  somewhat  faster  than 
a  mini-computer.  However,  because  of  the  low 
computation  nature  of  most  queries,  the  time  dif¬ 
ferential  would  become  insignificant.  The  greatest 
variance  would  be  in  the  type  of  data  base  manage¬ 
ment  system  used.  If  the  same  system  was  used, 
there  would  be  no  differences.  If  one  system  in¬ 
corporates  a  more  efficient  data  base  management 
system  for  this  program,  it  would  have  a  slight 
advantage. 


The  only  significant  differences  among  the  ACOs  re¬ 
sult  from  the  general  characteristics  of  mini¬ 
computers,  and  the  fact  that  the  UNIVAC  1100  used 
for  the  MTD  and  SAMF  ACOs  is  not  "dedicated".  On 
this  basis,  these  differences  may  become  signifi¬ 
cant  : 

1.  It  has  been  reported  that  in  the  past  the  MTD 
experienced  long  queues  (up  to  two  days)  for  ac¬ 
cess  to  the  DPFO.  This  condition  is  stated  to 
have  been  resolved.  SAMF  &  MTD  ACOs  could  experi¬ 
ence  the  same  queues.  On  the  other  hand,  the 
PFDB,  ADPE  and  SAMI  mini- computers  are  backed  up 
by  the  DPFO  only  during  high  peak  workload. 

2.  The  multiple  users  of  the  UNIVAC  1100  in  the 
TRADOC  DPFO  can  significantly  limit  the  total 
space  available  to  TRADES  for  extracting  large 
data  bases  from  automatic  data  sources  for  in¬ 
ternal  processing  as  well  as  for  the  storage  of 
corporate  memory  data  in  the  management  module. 
Furthermore,  accessibility  of  the  DPFO  (dis¬ 
cussed  above)  may  limit  the  usefulness  of  these 
ACOs  for  data  entry  by  the  RAM  users  for  inde¬ 
pendent  statistical/analysis  module  processing. 
These  potential  limitations  may  be  overcome  by 
expansion  of  the  DPFO. 

As  to  the  stand-alone  mini-computer,  the 
extent  to  which  data  may  be  extracted  from 
sources,  or  the  available  corporate  memory 
storage,  will  be  limited  by  the  capacity  of  the 
system  selected  and  the  space  allocated  within 
its  mass  memory  for  such  activities. 


Accessibility  to  Proponents 


Table  8-1  notes  that  the  five  alternatives  have 
equal  characteristics  with  regard  to  accessibility. 
However,  the  concept  of  TRADES  should  be  that  the 
automatic  data  system  be  ultimately  directly  avail¬ 
able  to  all  TRADOC  proponents.  Accordingly,  ac¬ 
cess  by  voice  communication  should  eventually  be 
replaced  by  the  availability  of  terminals  to  all 
RAM  users. 
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Flexibility 

A  basic  concept  of  TRADES  is  for  each  ACO  to  in¬ 
clude  interactive  capability.  However,  on  occa¬ 
sion,  batch  processing  may  be  desirable.  The  DPFO 
and  OAD  mini-computers  currently  have  this  capabil¬ 
ity.  However,  depending  on  the  degree  of  desir¬ 
ability  of  batch  processing,  this  feature  may  not 
be  feasible  for  certain  low-cost  micro-computers 
that  may  be  provided  each  user  as  a  terminal.  If 
batch  processing  is  a  definite  requirement  at  the 
user,  the  available  choice  of  micro-computers  as 
terminals  is  more  restricted. 

The  overall  TRADES  SRD  established  operational 
flexibility  requirements.  Addressed  elsewhere, 
they  concern  growth  potential,  EEI  expansion, 
number  of  users,  integration  with  other  systems, 
etc.  With  these  requirements,  all  ACOs  provide  a 
flexible  system. 

Integration  with 
Other  Systems 

This  requirement  addresses  the  ability  of  TRADES 
hardware/software  to  communicate  with  RAM  data 
sources  which  have  ADP  systems.  The  only  pres¬ 
ently  operating  system,  MTD,  has  full  capability 
of  communicating  with  all  other  large-scale  com¬ 
puter  systems  in  the  DA.  Such  capability  is  now 
widely  available  for  current  generation  systems, 
limited  in  some  cases  as  to  data  rate,  and  will  be 
accommodated  likewise  in  all  alternatives. 


Growth  Potential 

Since  the  MTD  and  SAMF  consider  that  TRADES  will  be 
resident  on  the  TRADOC  DPFO,  growth  potential  for 
TRADES  is  thus  limited  to  the  capacity  and  utiliza¬ 
tion  rates  allocated  by  the  computer  center  for 
TRADES.  This  does  not  obviate  procurement  of  ad¬ 
ditional  computer  facilities  at  the  DPFO  to  satisfy 
increasing  capacity  requirements.  However,  such 
expansion  programs  are  beyond  the  scope  of  this 
analysis . 


With  regard  to  the  mini-computer  ACOs,  it  is  con¬ 
sidered  that  there  is  no  near-term  limit  to  the 
growth  potential  of  TRADES  as  long  as  the  mini¬ 
computer  is  not  assigned  competing  tasks  of  higher 
priority.  It  is  unlikely  that  the  required  soft¬ 
ware  and  storage  capacity  will  exceed  the  limita¬ 
tion  of  the  general  category  of  hardware  designated 
as  mini-computers.  In  the  event  that  the  initial 
hardware  installation  becomes  limited,  it  could  be 
replaced  with  supplementary  or  additional  hardware 
at  relatively  low  cost  to  provide  necessary  growth. 

Resource  Requirements 

Resource  requirements  are  viewed  from  four  stand¬ 
points  -  additional  software,  hardware,  facilities 
and  personnel  directly  relatable  to  TRADES. 

Table  8-3  summarizes  the  relative  software  implica¬ 
tions  of  each  ACO,  providing  estimated  costs  and 
level  of  effect.  It  should  be  noted,  however,  that 
software  requirements  apply  only  to  the  actual  sys¬ 
tem  design,  prototyping,  and  initial  deployment  of 
TRADES  and  absolute  values  are  subject  to  revision 
in  the  light  of  lessons  learned  during  the  remaining 
TRADES  Phase  II  effort. 


TABLE  8-3.  ACO  COMPARISON  -  SOFTWARE  COSTS 


ACO 

EST.  DEVELOPMENT  COST* 

MAN-YEARS 

DESIGN** 

DEVELOPMENT** 

PFDB 

$400K 

3.25 

4 

MTD 

$350K 

3.50 

3.50 

ADPE 

$4Q0K 

3.25 

4 

SAMI 

$400 K 

3.25 

4 

SAMF 

$400K 

3.25 

4 

♦Current  DBMS  and  software  maintenance  are  sunk  costs.  Relative  values 
are  reasonably  correct.  Design/Development  based  on  very  preliminary 
estimate  of  approx.  10,000  lines  at  $40/1 ine. 

♦♦Based  on  system  design  effort  (man-months)  per  module: 

Exec.  Program  -  1  Interface  Module 

Source  Ident.  -  1  (15  data  systems)  -  30 

Quick  Response  -  1  Management  Module  -  5 

Stat. /Anal .Module  -  1 
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Development  of  the  source  identification  module  will 
constitute  a  major  initial  effort  of  TRADES,  and 
will  be  an  ongoing  requirement  throughout  its  life. 
During  its  initial  deployment,  TRADES  could  be 
limited  to  certain  commodity  areas,  or  selected  data 
sources.  Ultimately,  it  must  include  all  commodities 
and  sources,  as  well  as  be  maintained  on  a  regular 
date  routine. 

Table  8-2  summarized  the  hardware  requirements  for 
each  ACO.  Table  8-4  summarizes  the  costs  associated 
with  additional  hardware  that  must  be  purchased  for 
implementation  of  TRADES.  The  computers  and  periph¬ 
eral  equipment  available  at  OAD  and  the  DPFO  are 
sunk  costs.  Additional  procurements  are  limited  to 
terminals,  multiplexers  and  line  printers  for  RAM/ ILS 
and  the  users.  An  annual  operating  cost  is  included 
for  one  additional  dedicated  commo  line  from  RAM/ ILS 
to  the  TRADES  computer.  All  other  maintenance  costs 
are  assumed  absorbed  in  the  present  OAD  budget . 

The  additional  facilities  attributable  to  TRADES  are 
limited  to  the  requirements  of  the  additional  person¬ 
nel.  As  shown  in  Table  8-5,  each  person  is  provided 
a  standard  work  space  -  100  ft. 2  with  a  desk  and  file 
cabinet.  The  clerk  typist  is  furnished  a  work  station 
(which  includes  the  desk  and  associated  typist  equip¬ 
ment)  . 


All  ACOs  are  similar  other  than  the  PFDB  and  ADPE, 
each  of  which  require  one  additional  person  assigned 
to  OAD  on  an  "if  required"  basis  for  interface  ac¬ 
tivities.  Based  on  the  number  and  grade  structure 
of  additional  personnel  required,  Table  8-6  compares 
personnel  costs  for  each  ACO.  These  costs  are  based 
on  1981  salaries  plus  20%  for  overhead. 

The  total  resources  (cost)  differences  between  the 
ACOs  are  presented  in  Table  8-7.  From  these  results, 
it  is  seen  that  there  is  less  than  a  10%  difference 
in  development  costs  and  less  than  15%  difference  in 
annual  operating  cost.  Based  on  the  potential  sav¬ 
ing  that  can  be  accrued  by  providing  reliable  RAM 
data  to  the  TRADOC  community,  these  differences  be¬ 
come  insignificant. 
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the  subsequent  economic  analysis. 


TABLE  8-5.  ACO  COMPARISON  -  FACILITIES  COSTS 


■■ 

FACILITI 

ES  COST* 

KTCS1H 

FACILITIES 

INITIAL  INVEST. 

ANNUAL  COST 

PFDB 

700  ft^  Work  Space 

0 

7  Desks 

$1 ,400 

fill 

7  Secure  File  Cabinets 

$21,600 

0 

2  Typing  Stations 

$4,000 

0 

MTD 

600  ft^  Work  Space 

0 

$1,338 

6  Desks 

0 

6  Secure  File  Cabinets 

$14,800 

0 

2  Typing  Stations 

$4,000 

0 

ADPE 

(Same  as  PFDB} 

(Same  as 

PFDB) 

SAMI 

(Same  as  MTD) 

(Same  as  MTD) 

j 

SAMF 

(Same  as  MTD) 

(Same  as^  MTD) 

♦Based  on  Army  planning  factors  of: 

$2.23/ft2  annual  maintenance  cost  for  work  space; 

100  ft^  required  per  person;  $200  per  desk;  $2,800  per  secure 
file  cabinet;  $2,000  per  typewriter  with  desk  and  accessory 
equipment. 


TABLE  8-6.  ACO  COMPARISON  -  PERSONNEL  COSTS 


ACO 

NUMBER  OF  PERSONNEL 

ANNUAL  PERSOfi 

WIDISH 

RAM/ILS 

!»«■ 

PFDB 

6 

(4)  +  1* 

$200,000** 

bh 

MTD 

6 

(4) 

$200,000** 

0 

ADPE 

6 

(4)  +  1* 

$200,000** 

$36,700a 

SAMI 

6 

(4) 

$200,000** 

0 

SAMF 

6 

(4) 

$200,000** 

0 

♦Individual  is  "if  required"  for  interface  activities 
♦♦Based  on  1981  pay  scale  +  20$  overhead: 

3-GS-13 

l-GS-12 

1-GS-ll 

l-GS-04 

aBased  on  1981  pay  scale  for  one  GS-12  +  20$  overhead  increment. 
See  also  NOTE  on  Table  8-4,  Page  8-9 


8-10 


i 


TABLE  8-7.  COST*  SUMMARY  OF  ALTERNATIVES 
($000) 


DEVELOPMENT 

PFDB 

MTD 

ADPE 

SAMI 

SAMF 

Software 

Facilities 

Hardware 

1 

$350.0 

20.0 

184.3 

Iff 

K$TijW3H 

■  E 

— 

■O 

TOTAL 

$619.6 

$554.3 

$619.6 

$612.6 

$604.3 

OPERATING  (ANNUAL) 
Personnel 

Facilities 

Hardware 

$236.7 

1.5 

.7 

■ 

$236.7 

1.5 

.7 

$200.0 

1.3 

.7 

m 

TOTAL 

$238.9 

$212.1 

$238.9 

$202.0 

*1981  dollars;  not  rounded  to  preserve  audit  trail. 


Implementation  Time 

To  properly  assess  this  EEA,  certain  fundamental 

assumptions  must  be  accepted: 

1.  TRADES  will  be  categorized  as  a  Class  IV  ADP 
system  per  AR  18-1 

2.  The  MTD  and  SAMF  ACOs,  if  selected,  will  be  de¬ 
signed  to  reside  on  the  UNIVAC  1100  series  ADP 
system  at  the  TRAD0C  DPFO,  Fort  Leavenworth, 
Kansas 

3.  The  PFDB,  ADPE  and  SAMI  ACOs,  if  selected,  will 
be  designed  to  reside  on  the  OAD  mini-computers 
planned  for  procurement  and  will  have  the  DPFO 
available  for  backup  for  work  overflow  during 
peak  work  efforts 

4.  The  primary  responsibility  for  operational  sup¬ 
port  of  TRADES  will  be  assigned  to  an  existing 
division/branch  of  L0GC  as  an  additional  func¬ 
tion. 
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In  general,  implementation  time  for  the  PFDB,  ADPE, 
and  stand-alone  ACOs  should  be  equivalent.  Since 
development  effort  for  all  ACOs  will  be  in  excess 
of  $100,000  (but  under  $3M),  they  fall  within  a 
Class  IV  ADP,  require  a  product  manager  or  project 
officer  appointed  by  TRADOC,  with  system  approval 
at  TRADOC  level. 

In  accordance  with  Table  8-8,  TRADES  should  be  im¬ 
plemented  during  calendar  year  (and  fiscal  year) 
'85.  Rigid  adherence  to  the  approval  and  adminis¬ 
trative  cycles  is  required  in  order  to  provide  the 
software  developer  adequate  time  to  complete  the 
process.  Software  development  incorporates  system 
designs  to  the  DFSR  level  of  detail  programming, 
debugging,  prototyping,  and  system  demonstration. 


TABLE  8-8.  ACO  COMPARISONS  -  IMPLEMENTATION  SCHEDULES 


LIFE  CYCLE  STAGE 

MTD 

PFDB,  ADPE, 
SAMI,  SAMF 

ACO  Final  Report 

4  Feb.  1982 

4  Feb.  1982 

TRADOC  Approval 
(Class  IV  System) 

1  Aug.  1982 

1  Aug.  1982 

Date  of  Contract  - 
Software  Development 

1  March  1982 

1  March  1982 

System  Design  & 
Development  Completion 

1  Dec.  1984 

1  March  1985 

CHAPTER  IX 


CONCLUSIONS 

This  chapter  summarizes  the  results  of  the  analyses 
and  considerations  presented  in  the  earlier  chapters 
of  this  report. 

REQUIREMENT 

The  requirements  of  draft  AR  702-3,  setting  forth 
TRADOC' s  responsibility  to  maintain  a  central  acti¬ 
vity  for  the  proper  statement  and  justification  of 
RAM  characteristics  and  materiel  requirements  docu¬ 
ments,  was  a  key  consideration  in  structuring  the  re¬ 
spective  elements  of  TRADES. 

STRUCTURE  &  ENVIRONMENT 

TRADES  is  seen  as  an  information  system  serving  the 
requirements  of  the  RAM/ILS  community  of  TRADOC  as 
detailed  in  the  SRD  and  approved  by  SAG.  It  is  com¬ 
posed  of  functional  elements  supported  by  a  structure 
of  regulations,  procedures,  and  mechanization  to 
facilitate  its  activities.  The  functional  organiza¬ 
tion  is  charged  with  the  task  of  providing  reference 
and  tools  for  the  analysis  of  RAM  data  to  the  wea¬ 
pon  system,  subsystem,  and  selected  component  levels. 

The  analysis  of  TRADES  and  its  alternative  concepts 
of  operation  considers  the  current  organization  and 
distribution  of  RAM  functions  within  TRADOC  to  be 
stable  and  continuing.  Thus,  the  RAM  engineers  in 
the  boards,  schools,  and  other  user  activities  retain 
full  and  complete  responsibility  for  what  data  they 
use  and  what  they  do  with  it.  The  TRADES  function  is 
to  facilitate  their  efforts. 

TRADES  is  seen  as  closely  interfaced  with  the  Army's 
evolving  system  for  acquiring,  structuring,  and  using 
RAM  data.  It  must  be  created,  grow,  and  function 
effectively  through  a  significant  evolution  in  data 
sources,  principally  in  the  materiel  development  test 
and  acquisition  communities.  This  implies  the  capa¬ 
bility  of  addressing  both  hard  copy  and  automated  in¬ 
formation.  Initially,  there  is  a  heavy  emphasis  on 
hard  copy  from  all  levels,  with  a  gradual  shift  over 
the  next  four  to  six  years  into  mechanized  and  in¬ 
creasingly  interconnected  and  automated  information. 


The  basic  concept  of  TRADES  is  essentially  decen¬ 
tralized,  i.e.,  the  respective  proponent  activities 
and  users  retain  responsibility  for  the  quality  and 
utilization  of  RAM  data-  The  TRADES  task  is  to 
facilitate  their  rapid  access  to  a  remunerative  scope 
and  detail  of  information,  i.e.,  information  which 
the  user  judges  to  be  appropriate  and  adequate  for 
him  to  do  the  job  he  is  tasked  to  do. 

As  TRADES  begins  to  function  and  facilitate  the  work 
of  the  users,  demands  will  change  in  response  to  new 
capabilities.  Therefore,  the  TRADES  system  is  also 
evolutionary  in  the  sense  of  elements  and  structure. 
New  capabilities  provide  an  improved  potential  to 
satisfy  the  RAM/ILS  goals  of  an  effective  Army  material 
system. 

FUNCTIONS 

In  designing  TRADES,  our  objective  was  to  set  out 
what  had  to  be  accomplished  in  all  functional  acti¬ 
vities,  i.e. ,  mission  and  functions,  scope  and 
content  of  TRADES  activity. 

TRADES  must  identify  sources,  access  them,  and  pro¬ 
vide  for  their  analysis  in  format(s)  required  by  the 
TRADES  RAM  community.  Additionally,  a  method  must 
be  provided  for  a  "corporate  memory"  of  results, 
quick  response  for  applications  which  are  severely 
time  limited,  as  well  as  data  for  the  management  and 
growth  of  TRADES. 

These  are  embodied  in  five  basic  modules  detailed  in 
Chapter  II: 

1.  Source  identification 

2.  Interface 

3.  Quick  Response 

4.  Statistical/analytical 

5.  Management. 

ORGANIZATION 

The  TRADES  functional  implementation  implies  the  es¬ 
tablishment  of  a  branch  within  the  RAM/ILS  Division, 
with  a  Branch  Chief  responsible  for  planning,  and 
two  analysts  with  special  expertise  in  reliability 


and  statistics,  responsible  for  methodology  develop¬ 
ment,  analysis  and  special  studies.  These  two  spaces 
recognize  the  need  for  statistical  and  analytical 
skills  "across-the-board"  relating  to  the  RAM  area  as 
specifically  associated  with  TRADES. 

Additionally  required  is  a  RAM  engineer  and  a  computer 
specialist  to  provide  customer  service,  and 
the  activities  implied  in  the  TRADES  evolutionary  con¬ 
cept  of  operation.  A  clerk/typist  individual  with 
background  in  data  entry  and  extraction  is  also 
needed.  This  individual  should  have  career  develop¬ 
ment  potential. 

TRADES  MECHANIZATION 
ACTIVITIES 

The  "alternative  concepts  of  operation"  relate  to  only 
one  very  significant  phase,  i.e.,  methods  of  computer 
mechanization . 

The  APJ  approach  takes  maximum  advantage  of  the  avail¬ 
ability  of  existing  hardware  and  sunk  costs,  and  re¬ 
quires  only  modest  hardware  necessary  to  provide  access 
Resources  are  thereby  focussed  on  system  development 
and  implementation. 

The  method  of  evaluation  was  to  hold  the  required 
capabilities  roughly  equal  and  measure  the  differing 
cost,  time,  and  practicalities  of  implementation. 

Four  major  ACOs  analyzed  met  the  EEAs: 

1.  LOGC  MTD  System.  This  is  an  implemented  computer 
system  for  establishing  maintenance  task  demands. 
Only  a  few  data  elements  were  found  to  be  common. 
Hence,  the  structure  of  functional  modules  for 
TRADES  would  have  to  be  programmed  from  scratch 
and  the  only  gain  would  be  through  joining  an  al¬ 
ready  established  data  system,  i.e.,  the  availa¬ 
bility  of  established  administrative  and  operating 
practices . 


2.  The  Planning  Factors  Data  Base  is  an  approved 
concept  now  in  the  DFSR  phase,  with  authority 
already  provided  to  continue  this  development. 

PFDB  is  an  "umbrella"  which  plans  to  utilize 
inputs  from  numerous  logistical  data  systems  to 
establish  Army  planning  data.  PFDB  clearly  and 
legitimately  claims  MTD  as  a  module,  and  has  an 
equal  claim  tc  the  developed  TRADES.  This  does 
not  affect  TRADOC's  need  to  create  the  TRADES 
system,  which  then  functions  as  a  module  of  PFDB, 
in  the  same  sense  of  any  of  its  other  sources. 

3.  The  ADPE  concept  provides  a  structure  to  provide 
the  LOGCEN  with  an  on-site  computer  capability. 

As  the  master  plan  for  ADPE,  it  is  a  part  of  the 
TRADES  environment,  i.e. ,  any  mechanization  of 
TRADES  must  be  consistent  with  the  ADPE  concept 
and  structure.  ADPE  describes  equipment  poten¬ 
tials  and  has  time-share  capability  in  addition 
to  its  primary  justification  to  serve  LOGEX. 

4.  Stand-Alone  TRADES.  APJ  examined  two  alternative 
mechanizations:  the  first  is  a  concept  structure 
based  on  the  use  of  mini-computers  (SAMI);  an 
alternative  is  a  stand-alone  system  based  on  a 
main  frame  (SAMF).  Both  concepts  are  fully  con¬ 
sistent  and  compatible  with  PFDB  and  ADPE  concepts. 
The  first  approach  considers  the  utilization  of 
the  very  substantial  local  mini-computer  capabil¬ 
ity  planned  for  installation  at  the  LOGC.  The 
second  relies  on  the  main  frame  at  Fort  Leaven¬ 
worth  DPFO.  It  is  concluded  that  both  branches  of 
this  last  alternative  would  satisfy  the  TRADES 
mechanization  requirement.  Both  are  consistent 
with  the  ADPE  plan  and  the  PFDB  process. 

Cost  and  time  differences  among  all  the  mechanization 
alternatives  examined  were  found  to  be  insignificant. 
The  slight  advantage  of  MTD  was  within  the  bounds  of 
the  estimation  process. 

We  conclude  that  there  are  advantages  to  the  common 
location  of  OAD  and  the  TRADES  functional  activity, 
and  there  is  substantial  advantage  to  begin  the  im¬ 
plementation  of  TRADES  with  a  mini-computer.  Close 
access,  particularly  in  the  system  design  phases, 
is  clearly  essential,  and  the  inputs  of  the  users  and 
of  the  RAM  ILS  Division  are  absolutely  essential. 


Nevertheless,  it  is  also  a  requirement  that  the  pro¬ 
grams  be  "portable",  i.e.,  that  the  programs  and 
logic  not  be  specific  computer-peculiar  or  con¬ 
strained.  * 

It  is,  therefore,  concluded  that  implementation 
should  focus  on  creating  a  TRADES  system  which  will 
function  as  a  PFDB  module  in  a  manner  consistent  with 
the  overall  ADPE  plan. 

IMPLEMENTATION 

It  is  concluded  that  the  evolutionary  development  of 
TRADES  may  most  effectively  be  undertaken  by  taking 
steps  to  avoid  the  continued  loss  of  RAM  data,  and 
to  address  the  problems  of  hard  copy  retention, 
identification,  assessment  and  organization.  Further, 
that  implementation  of  TRADES  be  initiated  with  a  com¬ 
modity  area/activity  which  is  a  current  major  reposi¬ 
tory  of  RAM  data  so  that  the  entire  system  may  be 
exercised  and  lessons  learned  applied  to  create  a 
successful  TRADES. 

With  the  completion  of  concept  development,  there 
will  be  sufficient  information  and  structure  for 
definition  and  design,  system  development  and  deploy¬ 
ment,  to  proceed. 

It  is  finally  concluded  that  the  PFDB  ACO  should  be 
selected  for  the  further  development  of  TRADES.  This 
choice  was  carefully  considered  and  evaluated,  in 
recognition  of  the  fact  that  there  were  no  significant 
differences  among  the  ACOs.  The  operating  procedures 
and  response  times  to  the  users  do  not  vary  signifi¬ 
cantly  from  one  ACO  to  another.  It  is  APJ's  conclu¬ 
sion  that  the  state  of  system  development  of  PFDB 
provides  strong  administrative  advantages  to  the  de¬ 
velopment  and  subsequent  operation  of  the  TRADES  sys¬ 
tem. 


We  may  note  here  a  current  major  Navy  data  system  which 
was  operated  on  an  Air  Force  computer,  and  which  has  recently 
been  moved  to  an  Army  Computer  Center  based  on  considerations 
of  operating  economy  and  capability.  That  this  action  was 
feasible  was  because  system  design  and  programming  took  porta¬ 
bility  into  account  from  the  outset. 


In  the  broadest  sense,  TRADES  is  indeed  a  planning 
factor,  and  will  contain  useful  information,  e.g., 
repair  times,  repair  frequencies,  and  maintenance 
efforts  to  support  a  variety  of  combat  development 
actions.  These  include  such  activities  as  MACRIT, 
Maintenance  Manpower  Logistics  Analysis  (MMLA), 
wargaming,  and  other  simulations.  Because  of  this, 
and  a  similar  way  of  providing  customer  service, 
there  is  a  great  deal  of  compatibility  between 
TRADES  and  PFDB.  Thus,  customer  service  is  likely 
to  be  enhanced. 

Later  developmental  actions  in  both  management  and 
software  areas  may  likewise  be  facilitated,  with 
some  opportunities  to  conclude  selected  actions 
once,  rather  than  simultaneously.  Representative 
of  this  type  of  savings  would  be  the  selection  of 
a  DBMS  which  would  be  used  by  both  systems.  TRADES 
will  also  maximize  "sunk  costs"  of  equipment  already 
envisioned  for  PFDB.  However,  since  PFDB  require¬ 
ments  have  not  been  completely  finalized,  maximum 
consideration  for  and  accommodation  of  TRADES  re¬ 
quirements  may  be  made. 

The  organizational  structure  of  the  LOGC  provides  a 
clear-cut  division  of  responsibilities,  using  the 
PFDB  ACO.  The  Materiel  Directorate  would  retain 
functional  proponency  of  TRADES,  while  the  Opera¬ 
tions  Analysis  Directorate  would  develop  and  oper¬ 
ate  the  automated  system.  This  is  a  clearly  under¬ 
stood  method  of  operation  and  is  compatible  with 
the  current  organizational  responsibilities  within 
the  Logistics  Center. 

For  these  reasons,  and  those  noted  in  the  SRD  as 
well  as  in  earlier  portions  of  the  ACO,  it  is  con¬ 
cluded  that  the  PFDB  alternative  is  both  a  logical 
and  proper  choice  for  continued  development  of 
TRADES . 


CHAPTER  X 
RECOMMENDATIONS 


The  following  recommendations  are  based  on  the  ap¬ 
proved  SRD  and  on  the  conclusions  set  forth  in 

Chapter  IX. 

1.  That  the  TRADES  concept  development  be  com¬ 
pleted  and  that  succeeding  steps  relating  to 
system  definition  and  design,  development,  and 
deployment  be  undertaken 

2.  That  a  branch  charged  with  the  development  and 
implementation  of  TRADES  be  created  within  the 
RAM/ILS  Division  with  the  functions  and  manning 
recommended  in  Chapter  II 

3.  That  the  TRADES  logical  and  modular  structure 
be  developed 

4.  That,  in  programming  and  implementation  of 
TRADES,  full  advantage  be  taken  of  sunk  costs 
by  LOGC  and  TRADOC,  i.e.,  utilize  the  adminis¬ 
trative  facilitation  offered  by  the  approval 
and  implementation  stage  of  PFDB.  In  the  event 
that  progress  is  delayed,  recourse  should  be 
had  to  other  approved  systems 

5.  That  the  firm  requirement  be  established  that 
the  TRADES  system  mechanization  be  portable, 
with  capability  for  installation  with  minimum 
change  on  the  1984  generation  of  computers 
available  to  the  Army,  either  directly  or 
through  inter-Service  agreements 

6.  That  in  parallel  with  TRADES  mechanization 
activities,  effort  involving  source  identifica¬ 
tion  and  hard  copy  operations,  be  initiated. 
Actions  should  be  taken  to  inventory,  identify, 
assess,  and  render  accessible  hard  copy  informa¬ 
tion  within  the  TRADOC  community 

7.  That  a  planned  implementation  date  of  early 
1985  for  the  developed  TRADES  system  be  adopted 

8.  That  an  Army  regulation  be  prepared  to  formalize 
TRADES  in  the  Army  structure. 

9.  That  a  parallel  effort  within  TRADOC  be  implemen¬ 
ted  to  initiate  a  standardized  data  collection 
system  which  will  provide  computerized  data  for 
use  in  TRADES. 
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GLOSSARY 


ACO 

ADPE 

AMDF 

APJ 


Alternative  Concept  of  Operation 
Automatic  Data  Processing  Equipment 
Army  Master  Data  File 
American  Power  Jet  Company 


CRT 


Cathode  Ray  Tube 


DFSR 

DLSIE 

DPFO 

DTIC 


Detailed  Functional  System  Requirements 
Defense  Logistics  Studies  Information  Exchange 
Data  Processing  Field  Office 
Defense  Technical  Information  Center 


EEA 

EEI 


Essential  Elements  of  Analysis 
Essential  Elements  of  Information 


FSR 


Final  Study  Report 


LIF 

LOGEX 

LSAR 


Logistics  Intelligence  File 

Logistics  Exercise 

Logistics  Support  Analysis  Report 


MACRIT 

MTBF 

MTBOMF 

MTBUMA 

MTD 

MTTR 


Manpower  Authorization  Standards  &  Criteria 
Mean  Time  Between  Failures 

Mean  Time  Between  Operational  Mission  Failures 
Mean  Time  Between  Unscheduled  Maintenance  Actions 
Maintenance  Task  Demand 
Mean  Time  to  Repair 


OAD 

OTEA 


Operations  Analysis  Directorate 

(US)  Army  Operational  Test  &  Evaluation  Agency 


PFDB  Planning  Factors  Data  Base 

PFMD  Planning  Factors  Management  Division 


RAM 


Reliability,  Availability,  Maintainability 


SACS 

SAG 

SAMS 

SDC 

SOW 

SRD 

STP 

SWP 


Structure  and  Composition  System 
Study  Advisory  Group 
Standard  Army  Maintenance  System 
Sample  Data  Collection 
Statement  of  Work 
System  Requirements  Description 
System  Technical  Paper 
Study  Work  Plan 


GLOSSARY  (Concluded) 


TECOM 

TO&E 

TRADES 

TRADOC 

TSM 


(US)  Army  Test  and  Evaluation  Command 
Table  of  Organization  &  Equipment 
TRADOC  RAM  Data  Evaluation  Study 
(US;  Army  Training  and  Doctrine  Command 
TRADOC  System  Manager 


